#refarch (2024-07)

Cloud Posse Reference Architecture

2024-07-02

Taimur Gibson avatar
Taimur Gibson

Hi, how would I use assume_role_conditions in the iam-role module to set a condition to require an STS external ID for role assumption? https://github.com/cloudposse/terraform-aws-components/tree/main/modules/iam-role#input_assume_role_conditions

1
Gabriela Campana (Cloud Posse) avatar
Gabriela Campana (Cloud Posse)

@Dan Miller (Cloud Posse)

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

Take a look at the module here: https://github.com/cloudposse/terraform-aws-iam-role/blob/main/variables.tf#L64-L78

Then you can list the condition with test, variable, and values following the Terraform resource documentation here: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/iam_policy_document#source_policy_documents

All given conditions defined by var.assume_role_conditions will be included for the iam policy doc using the given allow actions defined by var.assume_role_actions

variable "assume_role_actions" {
  type        = list(string)
  default     = ["sts:AssumeRole", "sts:TagSession"]
  description = "The IAM action to be granted by the AssumeRole policy"
}

variable "assume_role_conditions" {
  type = list(object({
    test     = string
    variable = string
    values   = list(string)
  }))
  description = "List of conditions for the assume role policy"
  default     = []
}
Taimur Gibson avatar
Taimur Gibson

Thanks, this got me where I needed to be

2

2024-07-03

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

@Marat Bakeev following up from office hours today

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

can you please summarize the issue with the webhook secret? I will rope in our SME on actions runner controller

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

cc @Jeremy G (Cloud Posse)

Marat Bakeev avatar
Marat Bakeev

Sure. So, the issue is - we’re using actions-runner-controller. Our webhook logs state that there is no webhook secret configured:
2024-07-03T2022Z INFO -github-webhook-secret-token and GITHUB_WEBHOOK_SECRET_TOKEN are missing or empty. Create one following https://docs.github.com/en/developers/webhooks-and-events/securing-your-webhooks and specify it via the flag or the envvar

Jeremy G (Cloud Posse) avatar
Jeremy G (Cloud Posse)

Yes, sorry, that is a known issue, too, should be fixed this week.

2
Marat Bakeev avatar
Marat Bakeev

We have created the webhook and it’s secret in github, and also placed the secret into SSM. And it’s available there. But the secret controller-manager does not have the key for this webhook secret

Marat Bakeev avatar
Marat Bakeev

ah, okay, no worries. thanks

Jeremy G (Cloud Posse) avatar
Jeremy G (Cloud Posse)

@Marat Bakeev This has been fixed in Components v1.470.0.

3

2024-07-08

2024-07-18

Marat Bakeev avatar
Marat Bakeev

Do you guys have plans to update ArgoCD version? I think the one you have enabled (2.5.9) has a security issue, plus later versions add support for ApplicationSet Progressive Syncs.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

All our updates are (financially) sponsored by customers, or open source contributors

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We are open to updating everything :-)

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@Michael maybe something interesting for you?

Michael avatar
Michael

This is a great recommendation! I’ll take a look into it today!

Michael avatar
Michael

@Marat Bakeev Just to confirm, this is in reference to the CloudPosse packages repositories?

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

No, our components for ArgoCD need updates

1
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

(same ones you’re using, I think)

Michael avatar
Michael

Created a GitHub issue so I can track the work on this! https://github.com/cloudposse/terraform-aws-components/issues/1079

#1079 Upgrade Supported ArgoCD Chart Version

Describe the Feature

Argo versions 0.1.0 through 2.10.0-rc1, v2.9.3, v2.8.7, v2.7.15 are affected by CVE-2024-22424, a CSRF attack when the attacker has the ability to write HTML to a page on the same parent domain as Argo CD.

Expected Behavior

Propose that we update the default values for Argo’s chart from:

argo/argo-cd 5.19.12 v2.5.9

to an unaffected version patched after 2.10-rc2, 2.9.4, 2.8.8, 2.7.16

Use Case

N/A

Describe Ideal Solution

Update default value for:

variable “chart_version” { type = string description = “Specify the exact chart version to install. If this is not specified, the latest version is installed.” default = “5.19.12” }

And validate it works as intended

Alternatives Considered

No response

Additional Context

No response

Michael avatar
Michael
#1081 Upgrade Supported ArgoCD Chart Version

what and why

• Argo versions 0.1.0 through 2.10.0-rc1, v2.9.3, v2.8.7, v2.7.15 are affected by CVE-2024-22424, a CSRF attack when the attacker has the ability to write HTML to a page on the same parent domain as Argo CD. • Propose that we update the default values for Argo’s chart from:

argo/argo-cd 5.19.12 v2.5.9

to an unaffected version patched after 2.10-rc2, 2.9.4, 2.8.8, 2.7.16

notable changes

• Argo CD 2.10 upgraded kubectl from 1.24 to 1.26. This upgrade introduced a change where client-side-applied labels and annotations are no longer preserved when using a server-side kubectl apply • Note that bundled Helm version has been upgraded from 3.13.2 to 3.14.3 • Starting with Argo CD 2.10.11, the NetworkPolicy for the argocd-redis and argocd-redis-ha-haproxy dropped Egress restrictions. This change was made to allow access to the Kubernetes API to create a secret to secure Redis access

testing

• This version has been tested and verified to work with the existing component configuration

references

Argo Upgrade Docs

2024-07-19

2024-07-22

    keyboard_arrow_up