remove the quotes around [data.xxx](http://data.xxx)

may be that ? https://registry.terraform.io/providers/hashicorp/random/latest/docs/resources/uuid

thanks for the response @Dominique Dumont to provide more context the secret name (named after cluster UUID). so want to find out if this can be accomplished using tag’s of the secret (in data source using tags vs name or arn)

@Dan Miller (Cloud Posse)

It’s always best to not hard-code any secrets in terraform. There are many ways to retrieve an existing secret from data source, but I prefer using AWS SSM. Check out this blog post: https://blog.gruntwork.io/a-comprehensive-guide-to-managing-secrets-in-your-terraform-code-1d586955ace1

Hey Dan - the secret is not hard coded. Not sure if I put my question right.

the only way to retrieve a secret is thru name or arn and cannot be done via tags right?

Where is the secret stored?

secrets manager

with secrets manager you can only use name or arn to find the secret: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/secretsmanager_secret

thank you @Dan Miller (Cloud Posse) for your responses and @Gabriela Campana (Cloud Posse) for looping in Dan to address questions of many that were left unanswered.

Atmos is cloud agnostic

atmos does not know anything about cloud, it only understand yaml and render input variables used for different things

if you want cloudposse like modules for azure, we have a few here: https://github.com/slalombuild/terraform-accelerator

Hi @jose.amengual This is exactly it! Starting with the azure state module! Thanks!

Thanks Pepe for the helpful project

@Kris Musard sorry I missed your message.

We have an enormous enterprise customer using Atmos on Azure.

@jose.amengual super cool!

Here are some examples for Digital Ocean https://github.com/leb4r/terraform-do-components

dynamodb locking should force only one user to plan and apply

that’s not what I’m referring to, not at the same moment, in the same time window

if I apply my changes it looks, makes the changes to tfstate in s3, unlocks; I haven’t committed the code from my branch yet because I’m still testing that my changes will do what I think (eg, IAM changes, I am using the policy simulator on the new group I created via my tf apply)

then another devops person wants to test their changes so they apply, but tf will plan to remove the resources that my apply created because my code changes are not on that user’s checkout

what I’m doing right now is making my changes in a submodule and terraform apply there without a backend; however this only works because my changes are pure creation of new resources, no edits to existing resources

it’s like the only way to do this is to share branches or base my branch on the other other’s, but this only helps me see the other user’s changes, does not help them see my changes

1. Maintain the lock until you are ready to merge
2. Tf cloud does a plan in the PR and runs the apply on merge into master
3. Run the apply in the PR and merge immediately and if you need to make changes open a new PR. Those are the three ways I have seen it done. Presumably you are running your changes in a lower env first so a broken env is tolerable for a short time

how do you do #1? AFAIK the lock is automatically released at the end of an apply

You would have to relock after the apply. So technically you are releasing and then reacquiring the lock. https://github.com/minamijoyo/tflock

Interesting, I’ve often wished for a terraform lock command for this reason… I’ll have to check how robustly this can work for our team.

Thanks for sharing your ideas. #2 and 3 I had thought of but no gha in place yet so had to eliminate (or at least delay till other things have been done)

So much to unpack here

1. I’d get your TF applying exclusively through a workflow triggered by a push to main.

Secondly, it seems like you are worried about people creating some configuration, doing a pull request, waiting for approval, then merging it in and seeing something didn’t work and having to do that all over again

If that’s your main concern I would just create processes to let people merge their own PRs without approval or push straight to main.

There’s no law that says you pull requests require code reviews before merging. And if people are applying from their laptops all your PRs are just empty ceremony anyways

can’t do that because that would like not having PRs

Pull requests != Code Reviews

And Code Reviews != Approval Gates

Neat! Is there an out of the box action for this tool?

It would be nice to add it to this list too

https://github.com/shuaibiyy/awesome-terraform

Or better yet it would be great to add a rule to tflint or a custom ruleset

https://github.com/suzuki-shunsuke/tfprovidercheck/issues/19 https://github.com/terraform-linters/tflint-ruleset-terraform/issues/146

Thank you! I opened a pull request. https://github.com/shuaibiyy/awesome-terraform/pull/233

Is there an out of the box action for this tool? There is no GitHub Actions or something like that, but you can install and run this easily.

Wow! The pull request was merged in a flash!

Also cool would be to integrate with GitHub CodeQL.

See example: https://aquasecurity.github.io/tfsec/v1.0.11/getting-started/configuration/github-actions/github-action/

      - name: Upload SARIF file
        uses: github/codeql-action/upload-sarif@v1
        with:
          # Path to SARIF file relative to the root of the repository
          sarif_file: tfsec.sarif  

Then it would show up on the security tab

https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning

try this instead

terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

from https://registry.terraform.io/providers/digitalocean/digitalocean/latest/docs

what you have should work… the 2.31.0 version is pushed on github and the tf registry. if the ~> 2.0 works then the issue is something else.

@Brian Adams are you sure that this is the only place the version is constrained? Double-check the output of the init for contradictory version contraints.

I am just going to download the provider and use it locally.

did using ~> 2.0 not work?

Nope.

If you can share a screen shot of the init output and the output of terraform versions, might help us help you

@Max Lobur (Cloud Posse)

It’s a PAT as described here https://docs.aws.amazon.com/codepipeline/latest/userguide/appendix-github-oauth.html

Note that cicd and ecs-codepipeline might not work with the current version of AWS APIs because of deprecations of Github version : https://docs.aws.amazon.com/codepipeline/latest/userguide/update-github-action-connections.html . We will be doing this refactoring in related modules soon

https://discuss.hashicorp.com/t/renaming-github-namespace-with-modules-published/27762

Ugh, that sucks.

Thanks @Josh Pollara

guessing the aws_codebuild_project resource doesn’t have an auth parameter, but you might want to double-check the terraform resource docs on that one

Never used codebuild, but guessing that’s someone else’s module and that it worked at some point, so you may want to check when that feature was moved and pin the provider better. But also, dynamic is generally used because some data is getting pulled out of a dataset - if you’re not defining that part of the data, you can just remove it. You might also be pinned to/pulling from an older version of the module (and it’s now fixed) - you might want to look at the module’s repo and your source line.

this is done in the eks/cluster component, see https://github.com/cloudposse/terraform-aws-components/blob/main/modules/eks/cluster/main.tf#L46

ah, thanks, trying to figure out how to use cloudposse/terraform-aws-components It isnt TF module like cloudposse/terraform-aws-eks-cluster , right ?

we have TF modules in our repos, and TF components in https://github.com/cloudposse/terraform-aws-components. TF components a top-level Terraform root modules https://developer.hashicorp.com/terraform/language/modules#the-root-module

I see, but how can I enable aws-config module with enabled Karpenter role in a cluster created cloudposse/terraform-aws-eks-cluster without atmos?

the components use the modules (one or many) to define a deployable configuration. For example, the eks component (root module) https://github.com/cloudposse/terraform-aws-components/tree/main/modules/eks/cluster uses the eks-cluster child module https://github.com/cloudposse/terraform-aws-components/blob/main/modules/eks/cluster/main.tf#L131C25-L131C36, the eks-node-group module https://github.com/cloudposse/terraform-aws-components/blob/main/modules/eks/cluster/modules/node_group_by_az/main.tf#L34C25-L34C39 and manu=y others to define a complete configuration to deploy an EKS cluster

I see, but how can I enable aws-config module with enabled Karpenter role in a cluster created cloudposse/terraform-aws-eks-cluster without atmos?

it has nothing to do with Atmos

use the component and provide all the required variables https://github.com/cloudposse/terraform-aws-components/blob/main/modules/eks/cluster/variables.tf

you use Atmos to manage those variables for diff environments, accounts, OUs, regions etc. to make the config DRY

if you don’t use Atmos, you provide all those variables in some other TF files in your repo

oh, I see, so the component is actually wrapping tf modules, the problem is I used the eks module directly

components are wrappers on top of modules, yes

components are also TF root modules

they are more high level than modules

they can be used with Atmos and without. As mentioned, Atmos is used to manage the configuration for the components in a reusable and DRY way for many diff environments

then I am screwed, I have a lot of infra created directly via cloudposse modules, only thing left is to edit aws-auth configmap, so migration to the components would not make a sense now

you can definitely copy some parts of the code to deal with the karpenter role and auth map from our EKS component into your code

you have infra created from the EKS and karpenter modules, which means you have already created your own component

you can add any code to your component

What is editing aws-auth CM ? I see that every terraform-aws-eks-node-group is added there, but not sure how its exactly done. aws_eks_node_group TF resource?

are you using the node groups or karpenter (they are diff things), or both?

I have default one , trying to replace cluster-autoscaler. Karpenter needs some node for its controller, right ? I have created roles, policies, only thing needed is to edit that aws-auth CM.

• Add this file into your folder https://github.com/cloudposse/terraform-aws-components/blob/main/modules/eks/cluster/karpenter.tf - it creates the karpenter role with all the required permissions

• Add this code

worker_role_arns = compact(concat(
    var.map_additional_worker_roles,
    [local.karpenter_role_arn]
  ))

• Use the worker_role_arns here https://github.com/cloudposse/terraform-aws-components/blob/main/modules/eks/cluster/main.tf#L205

Oh, got it,

  module "eks_cluster" {
    source = "cloudposse/eks-cluster/aws"
    workers_role_arns = [my-karpenter-role]
  }

right?

yes

worker_role_arns is then used in the EKS module to add it to the auth map https://github.com/cloudposse/terraform-aws-eks-cluster/blob/main/auth.tf#L52

This will definitely help, thanks a lot

https://github.com/hashicorp/terraform/issues/18366#issuecomment-401984797

@Jeremy White (Cloud Posse)

We’d recommend using #geodesic! https://github.com/cloudposse/geodesic

docker solves the “it works on my machine” issue. Everyone can have the same dev environment

Can you show us an example of the changes detected by Terraform on Windows ?

@Dan Miller (Cloud Posse)

I figured out what what it was… had to do with the newline going from mac to windows.. thanks!

great! glad you worked it out

I’ve successfully gotten this to work with a dynamic block statement, but then there’s a statement block for each and figure this can easily hit the character limit with a lot of ARNs. Thinking it would be nice to have this collapsed into a single policy statement

I’ve also done this in a hacky way by iterating over the variable list twice as local variables and then combining the lists

In that particular example, you can write just, resources = var.bucket_arns

lol I might be missing something. bucket_arns wont produce a list like:

    resources = [
        "arn:aws:s3:::bucket1",
        "arn:aws:s3:::bucket1/*",
        "arn:aws:s3:::bucket2",
        "arn:aws:s3:::bucket2/*",
        "arn:aws:s3:::bucket3",
        "arn:aws:s3:::bucket3/*"
        ] 

True, but neither will your example! But ok I understand what you’re going for now. That’s a little trickier. You need each loop to produce a list of two items, the bucket arn and the object arn. And you need flatten to collapse the list of lists into one list

On my phone, so can’t provide code. And I’m off to bed. If you don’t get it by morning, I’ll expand more with code

all good, no rush

just a problem I’ve been working on today and was wondering how others have addressed this

another acceptable answer would be “you’re overthinking this, just put each line item in the statement resource and call it a day”

[ bucket, "${bucket}/*" ] creates the list of two items

Then wrap the whole for expression inside flatten([ for ... ])

you’re right, that works

for anyone following along:

data "aws_iam_policy_document" "example" {

  statement {
    actions   = ["s3:*"]
    effect = "Allow"
    resources = flatten([for bucket in var.bucket_arns : [ bucket, "${bucket}/*" ]])
  }
}

That’s it, yeah

Thank you all so much!

Looking for a 2 day classes

only in panama. have you tried contacting hashicorp to see if they keep a registry of trainers?

@Matt Gowie didn’t you used to do something in this space?

Yeah I used to do terraform trainings for a couple big companies, Salesforce and Deloitte. It was through DevelopIntelligence. Happy to put you in touch with them @RB

Thanks Matt!

i’d like to see the multi-account, multi-region project structure lol. struggling with that myself at the moment (again)…

Check out this as a multi account / region reference if you use atmos.

https://github.com/cloudposse/atmos/tree/master/examples/complete

If terragrunt, they have a similar refarch too that

hmm, ok, thanks! iiuc, the stacks tenant1/dev and tenant1/test1 have a multi-region setup

Yes so to deploy the same component (tf root dir) across 2 regions (us-east-2, us-west-2), it would be like this

atmos terraform plan vpc -- stack tenant1-ue2-dev
atmos terraform plan vpc -- stack tenant1-uw2-dev

https://github.com/cloudposse/atmos/tree/master/examples/complete/stacks/orgs/cp/tenant1/dev

Another question on that @RB… how is the account created in the first place? I assume it is still a two-step process, create the account, then deploy the stack to the account. Is the account creation done with terraform or something else? And is creation plus assignment of a stack all part of one workflow, or two separate ones?

yes, account creation is done with a separate component. i think it’s the account component.

https://github.com/cloudposse/terraform-aws-components/tree/main/modules/account

let’s say you’re adding a new dev account here under the plat tenant

components:
  terraform:
    account:
      vars:
          organizational_units:
            - name: plat
              accounts:
                - name: plat-dev
                  tenant: plat
                  stage: dev
                  tags:
                    eks: false

then the command to create the account

atmos terraform plan account --stack core-gbl-root

@loren would love to show a demo sometime

@Dan Miller (Cloud Posse) @Jeremy G (Cloud Posse)

if youre using google you should know that amazon now supports google natively, so you dont need ssosync https://aws.amazon.com/about-aws/whats-new/2023/06/aws-iam-identity-center-automated-user-provisioning-google-workspace/

ohhhh that is awesome news!!!

regarding deployment, you can deploy it to root or any other account that is delegated as an “administrator”. For example we’ve deployed it to identity in the past. But now we only deploy to root, since it’s generally easier to manage. It’s preference

the component is only deployed once to whichever account you choose as the administrator

but then the user roles, poweruser, admin etc you guys deploy it to identity or the root?

basically the aws-teams etc and so

sso only deploys the PermissionSets to the single account. then we use aws-teams/team-roles to deploy roles for terraform, etc

1. sso to the root (or identity) account (1 deployment)
2. aws-teams to identity account (1 deployment)
3. aws-team-roles to all other accounts (many deployments)

this is part of our reference architecture https://docs.cloudposse.com/reference-architecture/fundamentals/iam-identity/#our-solution

ok so the teams permissions sets are on root, then they assume a role in identity and then role chaining into the other accounts

yeah exactly. We also deploy PermissionSets directly with sso for each account entirely for convenience sake

those Permission Sets will allow access from SSO to the specific account directly. In UI for example

ahhh so if a developer needs console access to the dev account then a permission set is deployed into that account which matches the Gsuite group and then the user can log in directly?

yes or they can use role chaining. But direct access by the SSO login page tends to be easier

but to apply terraform and access state, you need to access the identity aws-team

but in that case why bother deploying permission sets to the root account for dev access using role chaining?

ahhh ok, you answered my question

well in my case a dev might not have ever access to the state

also in the case that you’re using both SAML and SSO to authenticate users

only the automation account which will run the pipelines

if devs only ever need access to 1 account and do not need to access state in some other account, then they probably do not need the chaining set up

entirely with SSO is likely good enough

yes, agree

Question @Dan Miller (Cloud Posse) the iam-roles needs to exist before deploying the aws-sso component? I’m getting errors trying to lookup stuff trying to deploy it

I’m in debug mode now…

I don’t believe it needs roles at all. The trust relationship is created by aws-teams after sso is deployed

What’s the error?

many…

basically I do not use tenant so I need to do this part

## The overridable_* variables in this file provide Cloud Posse defaults.
## Because this module is used in bootstrapping Terraform, we do not configure
## these inputs in the normal way. Instead, to change the values, you should
## add a `variables_override.tf` file and change the default to the value you want.

for the iam-role submodule

and my root account is not called root

( I did not created it, somene else did)

so my account map is like this:

organization_config:
          root_account:
            name: PePe-Org
            stage: root
          accounts: []
          # organization:
            # service_control_policies:
            #   #- DenyEC2InstancesWithoutEncryptionInTransit
          organizational_units:
            - name: sandbox
              accounts: []
              service_control_policies:
                - DenyLeavingOrganization

etc…

and I do not use glb, I use global

so then i get this:

Error: Invalid index
│ 
│   on ../account-map/modules/iam-roles/main.tf line 44, in locals:
│   44:   static_terraform_role  = local.account_map.terraform_roles[local.account_name]
│     ├────────────────
│     │ local.account_map.terraform_roles is object with 8 attributes
│     │ local.account_name is "root"
│ 
│ The given key does not identify an element in this collection value.

Are you using the latest version of both account-map, tfstate, and teams? Also I just stepped away from the computer and am a little busy tonight, but I can take a more thorough look in the morning

not in a rush, I just pulled from main

so it looks like the code expect the root account be called root in the account component

 organization_config:
          root_account:
            name: root
            stage: root
          accounts: []
          # organization:
            # service_control_policies:
            #   #- DenyEC2InstancesWithoutEncryptionInTransit

After changing the name to root, I was able to go further into the aws-sso, but I think my assumption of roles to be in the accounts beforehand was right.

because now the aws-sso component is trying to assume

╷
│ Error: Cannot assume IAM Role
│ 
│   with provider["registry.terraform.io/hashicorp/aws"],
│   on providers.tf line 28, in provider "aws":
│   28: provider "aws" {
│ 
│ IAM Role (arn:aws:iam::22222222:role/pepe-global-root-admin) cannot be assumed.

I never deployed any roles to any of the accounts

they re all empty

You can set the root account name to whatever you like. For example, we use core-root

        organization_config:
          root_account:
            name: core-root
            stage: root
            tenant: core

Then in account-map, you can specify both the account alias and account name however you like

        root_account_aws_name: root
        root_account_account_name: core-root

is I use any name that is not root then it fails with those errors I posted earlier

Why is terraform trying to assume a role? In our case we use the SuperAdmin user, which has complete access, and we disable the backend

maybe is because I do not use tenant

I have no idea why; is my first time trying to deploy aws-sso

in my case I’m using root account creds with a role I created, not via SSO

If backend role is configured, then atmos will attempt to use that role to access tfstate. We set to null when we want to use the current role/user and not assume another role

I tried that, and I got the same error

now just 2 errors instead of 4

What’s your error?

this role:

arn:aws:iam::2222222:user/automation-root

is the one I’m currently using to deploy this

is not picking up my current role

ohh wait , I put the backend setting in the wrong place

mmm same

should I set privileged: false?

interesting If I set it to true then it complains about locals and other stuff but not any more the assume role

what is the difference between dynamic and static roles? how “dynamically” they are?

privileged: true is used to tell remote-state to use the current role to pull from the s3 backend

static roles are the previous behavior, where account-map always expected the terraform role to exist. dynamic roles use the configuration in aws-team/roles to dynamically find the name of the role

more on that with the comments I added with this PR: https://github.com/cloudposse/terraform-aws-components/pull/870

so TLDR, if you use dynamic roles, you need to have aws-team/roles configured in code. Not necessarily applied, but the following command should work:

atmos describe stacks --components=aws-teams,aws-team-roles --component-types=terraform --sections=vars

ohhh so the error I’m getting could be related to that

mmm

I don’t have those configured

but those components will be deployed on identy and all.other accounts ,not root , right ?

aws-teams is always deployed to identity, aws-team-roles is deployed to root (optionally) and all other accounts

if you dont have those configured, then I’d disable dynamic roles

I see , ok

(@Dan Miller (Cloud Posse) see the thread I tagged you in. TL;DR AWS SSO doesn’t work properly with Terraform with delegated administrator accounts.)
@Jeremy G (Cloud Posse): We were following the general pattern of delegating control to core-identity, but as you noticed, the delegated IAM administrator cannot itself manage the Permission Sets deployed to core-root . That means anyone running Terraform for aws-sso has to have admin access to core-root, which negates any benefit of the delegation. Since the delegation adds complexity without a security benefit, we gave up on it.

@Jeremy White (Cloud Posse) were you able to get the SSO integration working with GSuite? @jose.amengual has had some issues and was asking about it

Groups were not syncing automatically only users

from docs:

SCIM automatic synchronization from Google Workspace only supports provisioning users; groups aren't automatically provisioned. You can't create groups for your Google Workspace users using the AWS Management Console. After provisioning users, you can create groups using a CLI or API operation

https://docs.aws.amazon.com/singlesignon/latest/userguide/gs-gwp.html ( step 10)

so if you guys got this working without the sso-sync lambda I will like to know

@Dan Miller (Cloud Posse) can you chime in? I think we were just discussing this yesterday. I think due to the aforementioned problems with groups, I think the ssosync is still necessary.

@Jeremy White (Cloud Posse) implemented this recently and said that he was able to get it working but had to follow the steps very precisely. @Jeremy White (Cloud Posse) can you chime in please?

Sure, so there are two sets of instructions… one on the google side and another set on the AWS side which both ought to guide you through the steps of enabling the integration.The trickiest part is getting the automatic provisioning dialog to show up in Google Workspaces. I understand that others have gotten it working through these steps, and I’ve been on calls to guide people through them, and most of the time the reason it doesn’t work is a minuscule misstep here or there.

I got the automatic provisioning working fine for users but groups did not sync and base on the note on step 10 it looks like is not supported. did you get it working with groups?

so, two things:

1. group creation, update, and deletion is definitely not supported

1. users in groups works AFAIK. That is, once the group is created manually in Identity center, users will be assigned/unassigned correctly

ok, that confirms what the docs say about 1, Users worked fine but groups did not, so I had to deploy the sso-sync

just clarifying statement: ‘had to deploy’ sso-sync is for groups only. Users can be added to the groups by auto-provisioning. Is that how you have it configured now?

There is a small risk in this. Customers have reported back that ssosync can get confused and will delete/recreate groups. unfortunately, such an action will disconnect all permission sets and saml apps

auto-provisioning only synced users to Identity center

to be able to sync groups from google I had to deploy the ssosync

gotcha. And I’ll try to remember to tag you if auto-provisioning eventually adds group support

I think AWS/Google know this is still non-ideal

definitely and the problem is the comment is buried on a step by step guide

yes. To be clear, you need to scroll down to the https://docs.aws.amazon.com/singlesignon/latest/userguide/gs-gwp.html#<i class="em em-r2m"very bottom of the AWS Guide and click “next steps” before AWS spells out that they -do- in fact let you create the groups. (If you try to do it in the AWS Web Console, it blocks such interactions due to automated provisioning being enabled)

@Jeremy G (Cloud Posse) please make note of ^ . Dan brought it up that it could be unclear if you don’t follow every step of the guide

Basically, you can only create/delete groups via API once the automated provisioning is turned on

Now, I’m confused. @Jeremy White (Cloud Posse) what is current best practice for keeping Google groups in sync with AWS?

we’re discussing this right now on a call if you want to join, but TLDR the groups have to be created with API. They cannot be created manually

we can create them with Terraform

AWS tells you in the article that this is what they recommend

I’m adding it to the aws-sso component

That is creating them, but what about keeping them in sync?

Google integration for identity center. same as okta/jumpcloud/etc, but group creation is not supported

once the groups are created, then the integration will automatically sync

It seem so https://registry.terraform.io/providers/integrations/github/latest/docs/resources/organization_ruleset

@Andriy Knysh (Cloud Posse)

define a variable, mark it sensitive, and use it in the command of the local-exec

https://github.com/hashicorp/terraform/pull/26611

Thanks. I’m using a token from a data resource so I can’t set a variable to sensitive. I tried to achieve something similar by using

locals {
  ecr_password = sensitive(data.aws_ecr_authorization_token.default.password)
}

But this does not seem to work. The token is still printed in the logs in case of an error

@Matt Calhoun

I got it to work with the aforementioned module by making a few changes to it: https://github.com/flaupretre/terraform-ssh-tunnel/pull/30

We never had an issue like that as we provision AWS VPN primarily or run Terraform on instances inside of the perimeter. Your solution is great for achieving the goal.

i think the module needs to be updated https://github.com/cloudposse/terraform-aws-eks-workers/blob/main/main.tf#L168

0.30.1 is an old version

the latest one don’t use tags, it uses tag https://github.com/cloudposse/terraform-aws-ec2-autoscale-group/blob/main/main.tf#L268

PRs are welcome

in https://github.com/cloudposse/terraform-aws-eks-workers/blob/main/main.tf#L168, 0.30.1 needs to be updated to 0.39.0

then please run the following commands and commit the changes

make init
make github/init
make readme

also, why are you using the EKS workers and not Managed Node Groups (they are easier to deal with) or karpenter?

Thank you so much! The managed node groups seem to apply much better to my use case.

@Andriy Knysh (Cloud Posse) I used EKS workers because I’d like to set maximum number of pods to be created on a node to false, does managed node groups has same feature?

looks like you are trying to provision the cluster on Fargate. Check these variables https://github.com/cloudposse/terraform-aws-ecs-cluster/blob/main/variables.tf#L34

or you are saying that you want fargate and you have ALB (not classic), but the error says that the load balancer is classic?

look at this example which provisions ECS cluster and ALB https://github.com/cloudposse/terraform-aws-components/blob/main/modules/ecs/main.tf

I’m saying that I’m creating an Fargate ECS and an ALB but I can’t make the services to deploy correctly. Let me look at those examples and will get back here. Thanks!

module “ecs_cluster” { source = “cloudposse/ecs-cluster/aws”

enabled = var.enabled context = module.label.context

container_insights_enabled = var.container_insights_enabled logging = var.logging log_configuration = var.log_configuration capacity_providers_fargate = true tags = var.tags depends_on = [ module.label ] }

module “label” { source = “cloudposse/label/null” version = “0.25.0”

namespace = var.namespace name = var.cluster_name environment = var.environment tenant = var.tenant id_length_limit = 255

}

For the ECS example, it deploys the cluster and alb, but no services. The issue is with the service creation

Looking at: modules/ecs-service/main.tf

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service#load_balancer

so this is not correct

target_group_arn = null
elb_name         = module.alb.alb_name,

that’s it

you need the other way around

thanks! I will provide the target_groups instead

all resource names/IDs/ARNs are controlled by the label module https://github.com/cloudposse/terraform-aws-iam-role/blob/main/main.tf#L29

and the module accepts a bunch of variables to control its behavior, in this case you can use https://github.com/cloudposse/terraform-aws-iam-role/blob/main/context.tf#L242

module "iam-role" {
  source = "cloudposse/iam-role/aws"
  version     = "0.19.0"

  enabled   = true
  name      = var.wave_code_deploy_role_name

Thanks for the quick reply Andriy! I’m not sure how to connect it all - how do I make this name use label_value_case==’none’?

the module has context.tf file which has all the common vars (see https://github.com/cloudposse/terraform-aws-iam-role/blob/main/examples/complete/main.tf#L74C16-L74C16)

so when instantiating the module, you can provide label_value_case

got it! Thanks Andriy! (btw minor feedback - “none” as default would seem better to me since it would match the AWS Console behavior)

yes, maybe it would be better, but for historical reasons it’s set to lower and it’s already eveywhere so would be difficult to change

I believe this impacts wide range of deployments

aws doc on karpenter indicates URL

<oci://public.ecr.aws/karpenter/karpenter>

You may want to try that one. HTH

should work by attaching the same policy to 2 node groups

Yeh. I am not able to do that as during the second instantiation of the node group module . In blueprints, nodegroup’s policies and roles are created within node group module.

do you have the link to the blueprint, is it possible to pass a variable for the name of both nodegroups’ policies?

https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/patterns/fully-private-cluster

ok, this will use a community module, I guess you may customize the code?

Yeah nvm lol https://aws.amazon.com/blogs/aws/amazon-elasticache-serverless-for-redis-and-memcached-now-generally-available/

that’s lovely!