Skip to main content

Components Changelog

Subscribe through RSS feeds to stay up-to-date with new releases!

View on GitHub

fix: ecs capacity provider typing

What​

  • Adjust typing of capacity_providers_ec2

Why​

  • Component doesn't work without these fixes

🚀 Enhancements​

Update `alb` and `eks/alb-controller` components

What​

  • Update alb and eks/alb-controller components

Why​

  • Remove unused variables and locals
  • Apply variables that are defined in variables.tf but were not used

🚀 Enhancements​

[aws-teams] Remove obsolete restriction on assuming roles in identity account

What​

  • [aws-teams] Remove obsolete restriction on assuming roles in the identity account

Why​

Some time ago, there was an implied permission for any IAM role to assume any other IAM role in the same account if the originating role had sufficient permissions to perform sts:AssumeRole. For this reason, we had an explicit policy against assuming roles in the identity account.

AWS has removed that implied permission and now requires all roles to have explicit trust policies. Our current Team structure requires Teams (e.g. spacelift) to be able to assume roles in identity (e.g. planner). Therefore, the previous restriction is both not needed and actually hinders desired operation.

🚀 Enhancements​

[eks/karpenter-provisioner] minor improvements

What​

  • [eks/karpenter-provisioner]:
    • Implement metadata_options
    • Avoid Terraform errors by marking Provisoner spec.requirements a computed field
    • Add explicit error message about Consolidation and TTL Seconds After Empty being mutually exclusive
    • Add instance-category and instance-generation to example in README
    • Make many inputs optional
  • [eks/karpenter] Update README to indicate that version 0.19 or later of Karpenter is required to work with this code.

Why​

  • Bug Fix: Input was there, but was being ignored, leading to unexpected behavior
  • If a requirement that had a default value was not supplied, Terraform would fail with an error about inconsistent plans because Karpenter would fill in the default
  • Show some default values and how to override them
  • Reduce the burden of supplying empty fields

Add EKS addons and the required IRSA to the `eks` component

What​

  • Deprecate the eks-iam component
  • Add EKS addons and the required IRSA for the addons to the eks component
  • Add ability to specify configuration values and timeouts for addons
  • Add ability to deploy addons to Fargate when necessary
  • Add ability to omit specifying Availability Zones and infer them from private subnets
  • Add recommended but optional and requiring opt-in: use a single Fargate Pod Execution Role for all Fargate Profiles

Why​

  • The eks-iam component is not in use (we now create the IAM roles for Kubernetes Service Accounts in the https://github.com/cloudposse/terraform-aws-helm-release module), and has very old and outdated code

  • AWS recommends to provision the required EKS addons and not to rely on the managed addons (some of which are automatically provisioned by EKS on a cluster)

  • Some EKS addons (e.g. vpc-cni and aws-ebs-csi-driver) require an IAM Role for Kubernetes Service Account (IRSA) with specific permissions. Since these addons are critical for cluster functionality, we create the IRSA roles for the addons in the eks component and provide the role ARNs to the addons

  • Some EKS addons can be configured. In particular, coredns requires configuration to enable it to be deployed to Fargate.

  • Users relying on Karpenter to deploy all nodes and wanting to deploy coredns or aws-ebs-csi-driver addons need to deploy them to Fargate or else the EKS deployment will fail.

  • Enable DRY specification of Availability Zones, and use of AZ IDs, by reading the VPCs AZs.

  • A cluster needs only one Fargate Pod Execution Role, and it was a mistake to provision one for every profile. However, making the change would break existing clusters, so it is optional and requires opt-in.

References​

Make alb-controller default Ingress actually the default Ingress

What​

  • Make the alb-controller default Ingress actually the default Ingress

Why​

  • When setting default_ingress_enabled = true it is a reasonable expectation that the deployed Ingress be marked as the Default Ingress. The previous code suggests this was the intended behavior, but does not work with the current Helm chart and may have never worked.

Update `waf` and `alb` components

What​

  • Update waf component
  • Update alb component

Why​

References​

`acm` Upstream

What​

  • Upstream ACM

Why​

  • New Variables
    • subject_alternative_names_prefixes
    • domain_name_prefix

Upstream Spacelift and Documentation

What​

  • Minor corrections to spacelift components
  • Documentation

Why​

  • Deployed this at a customer and resolved the changed errors
  • Adding documentation for updated Spacelift design

References​

  • n/a

Upstream `gitops`

What​

  • Upstream new component, gitops

Why​

  • This component is used to create a role for GitHub to assume. This role is used to assume the gitops team and is required for enabling GitHub Action Terraform workflows

References​

  • JUMPSTART-904

Restore backwards compatibility of account-map output

What​

  • Restore backwards compatibility of account-map output

Why​

  • PR removed outputs from account-map that iam-roles relied on. Although it removed the references in iam-roles, this imposed an ordering on the upgrade: the iam-roles code had to be deployed before the module could be applied. That proved to be inconvenient. Furthermore, if a future account-map upgrade added outputs that iam-rolesrequired, neither order of operations would go smoothly. With this update, the standard practice of applyingaccount-map` before deploying code will work again.

Upgrade notes​

This fixes issues with aws-sso and github-oidc-provider. Versions from v1.227 through v1.240 should not be used.

After installing this version of aws-sso, you may need to change the configuration in your stacks. See modules/aws-sso/changelog for more information. Note: this release is from PR

After installing this version of github-oidc-provider, you may need to change the configuration in your stacks. See the release notes for v1.238.1 for more information.

🐛 Bug Fixes​

bugfix `aws-sso`, `github-oidc-provider`

What​

  • Bugfixes filter depreciation issue via module update to 1.1.1
  • Bugfixes missing aws.root provider
  • Bugfixes github-oidc-provider v1.238.1

Why​

  • Bugfixes

References​

Upgrade notes:​

There is a bug in this version of github-oidc-provider. Upgrade to version v1.240.1 or later instead.

After installing this version of github-oidc-provider, you may need to change the configuration in your stacks.

  • If you have dynamic Terraform roles enabled, then this should be configured like a normal component. The previous component may have required you to set

    ```yaml
    backend:
      s3:
        role_arn: null
    ````

    and that configuration should be removed everywhere.

  • If you only use SuperAdmin to deploy things to the identity account, then for the identity (and root, if applicable) account only, set

    ```yaml
    backend:
      s3:
        role_arn: null
    vars:
      superadmin: true
    ````

    Deployments to other accounts should not have any of those settings.

🚀 Enhancements​

[github-oidc-provider] extra-compatible provider

What && why​

  • This updates provider.tf to provide compatibility with various legacy configurations as well as the current reference architecture
  • This update does NOT require updating account-map

IAM upgrades: SSO Permission Sets as Teams, SourceIdentity support, region independence

What​

  • Enable SSO Permission Sets to function as teams
  • Allow SAML sign on via any regional endpoint, not only us-east-1
  • Allow use of AWS "Source Identity" for SAML and SSO users (not enabled for OIDC)

Why​

  • Reduce the friction between SSO permission sets and SAML roles by allowing people to use either interchangeably. (Almost. SSO permission sets do not yet have the same permissions as SAML roles in the identity account itself.)
  • Enable continued access in the event of a regional outage in us-east-1 as happened recently
  • Enable auditing of who is using assumed roles

References​

Upgrade notes​

The regional endpoints and Source Identity support are non-controversial and cannot be disabled. They do, however, require running terraform apply against aws-saml, aws-teams, and aws-team-roles in all accounts.

AWS SSO updates​

To enable SSO Permission Sets to function as teams, you need to update account-map and aws-sso, then apply changes to

  • tfstate-backend
  • aws-teams
  • aws-team-roles
  • aws-sso

This is all enabled by default. If you do not want it, you only need to update account-map, and add account-map/modules/roles-to-principles/variables_override.tf in which you set overridable_team_permission_sets_enabled to default to false

Under the old iam-primary-roles component, corresponding permission sets were named Identity<role>RoleAccess. Under the current aws-teams component, they are named Identity<role>TeamAccess. The current account-map defaults to the latter convention. To use the earlier convention, add account-map/modules/roles-to-principles/variables_override.tf in which you set overridable_team_permission_set_name_pattern to default to "Identity%sRoleAccess"

There is a chance the resulting trust policies will be too big, especially for tfstate-backend. If you get an error like

Cannot exceed quota for ACLSizePerRole: 2048

You need to request a quota increase (Quota Code L-C07B4B0D), which will be automatically granted, usually in about 5 minutes. The max quota is 4096, but we recommend increasing it to 3072 first, so you retain some breathing room for the future.