#terraform (2024-09)

@george.m.sedky is working on something, I think?

hey @Abhigya Wangoo it’s not no-code; it’s visual, you can import stuff, and write code to edit resources if needed. but give it a try and let me know what you think

if you’re looking for something pure no-code try Brainboard

i thought that adding this might help but it doesn’t seem to have any effect:

  allowed_security_group_ids = [
    "sg-0473cc37c73272716"
  ]

i used the wrong argument. never mind.

adding this:

  additional_security_group_rules = [
...
    {
      type                     = "ingress"
      from_port                = 2049
      to_port                  = 2049
      protocol                 = "tcp"
      cidr_blocks      = [
        "10.103.21.119/32",
    ]

yields this:

  # module.efs.module.security_group.aws_security_group_rule.dbc["_list_[1]"] will be created
  + resource "aws_security_group_rule" "dbc" {
      + cidr_blocks              = [
          + "10.103.21.119/32",
        ]
      + description              = "Allow jenkins-data-sync to access EFS"
      + from_port                = 2049
      + id                       = (known after apply)
      + prefix_list_ids          = []
      + protocol                 = "tcp"
      + security_group_id        = "sg-06fa9a39d9a9c6f77"
      + security_group_rule_id   = (known after apply)
      + self                     = false
      + source_security_group_id = (known after apply)
      + to_port                  = 2049
      + type                     = "ingress"
    }

which i’m not sure is expected or not.

never mind this one, too.

@Juan Pablo Lorier did you add this to [versions.tf](http://versions.tf) file

terraform {
  required_version = ">= 1.3.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"
    }
    awsutils = {
      source  = "cloudposse/awsutils"
      version = ">= 0.15.0"
    }
  }
}

and this to [providers.tf](http://providers.tf) file

provider "aws" {
  region = var.region

  assume_role {
    role_arn = ...
  }
}

provider "awsutils" {
  region = var.region

  assume_role {
    role_arn = ...
  }
}

the provider configuration is empty as I use OIDC to authenticate

in this case, you just need to add (assuming the role is not related to how to configure the provider itself)

provider "awsutils" {
  region = var.region
}

Thanks! I might open an issue to add that to the documentation. (both to the provider and to the vpn client as a dependency)

you need to do this only if you are using some old version of the awsutils provider

the latest version does not need the region config

see https://github.com/cloudposse/terraform-aws-components/tree/main/modules/ec2-client-vpn

I’m using the latest version of the module. But it’s not the module you pointed.

https://registry.terraform.io/modules/cloudposse/ec2-client-vpn/aws/latest

let me know if you are using the latest version and it still requires the region config

i pointed to the component that wraps the module

and yes, the module https://github.com/clouddrove/terraform-aws-client-vpn does not have the provider config (this needs to be fixed)

in the component (root-module), the provider config is added

awsutils = {
      source  = "cloudposse/awsutils"
      version = ">= 0.15.0"
    }

that’s why the component works

I’m using latest version. 1.0.0 and I’m facing the issue there

in your root-module (that uses <ttps://github.com/clouddrove/terraform-aws-client-vpn>) try to add

awsutils = {
      source  = "cloudposse/awsutils"
      version = ">= 0.15.0"
    }

about the clouddrove link, I pasted it by mistake, I was looking for alternatives to cloudposse as I was not able to get it to work

source = “cloudposse/ec2-client-vpn/aws” version = “1.0.0”

we provision the component https://github.com/cloudposse/terraform-aws-components/tree/main/modules/ec2-client-vpn all the time, it works

in your module, just add the awsutils config to [versions.tf](http://versions.tf)

it failed with only versions.tf. It worked when I added the provider config

awsutils = { source = “cloudposse/awsutils” version = “>= 0.19.1” } }

nice

(we have the config in [versions.tf](http://versions.tf) https://github.com/cloudposse/terraform-aws-components/blob/main/modules/ec2-client-vpn/versions.tf)

I see, but somehow, terraform was complaining. Maybe it’s related to using OIDC in terraform cloud?

should not be related to OIDC, but I’m glad you made it work

thanks for the help.

@Andriy Knysh (Cloud Posse) Sorry to bug you with this non terraform question. The module creates the certs and stores them in parameter store. But it creates only CA, root and server certs. Do I need to create the client certs manually?

I don’t think jsondecode() will give you exactly what you want, so within terraform this isn’t easy to solve. You can open a PR for a new variable accepting JSON input and I will review it!

As you see here the module eventually converts inputs to json, so if you’d rather just provide the json yourself that’s a good feature-add

i was looking for something like this but the syntax that the module expects. it’s slightly different than what terraform’s resource expects by default. i was able to to use that converter with a couple string replaces https://iampolicyconverter.com/

@Jeremy G (Cloud Posse)

The aws_iam_access_key docs say that secret and ses_smtp_password_v4 are not available for imported resources.

I think the procedure for rotating the key would simply be: • terraform state rm 'module.system_user.aws_iam_access_key.default[0]' to remove the current key from Terraform control • terraform apply to create the new key • Later, delete the old key manually via aws

Thank you very much, @Jeremy G (Cloud Posse)! Everything worked great!

Hey Mike!

I used a similar setup in a previous role, and it worked well enough, but it depends on how much you plan to scale your infrastructure repository. As our monorepo grew, we ran into limitations with the pipelines, and GitLab’s child pipelines could only take us so far. Our biggest regret was relying on GitLab’s managed state, which became a bottleneck when we moved to a polyrepo pattern for our microservices. This also led to dependency hell as we tried to maintain consistency across all repositories.

I’ve always been a fan of how Atmos offers straightforward design patterns and inheritance, making monorepo management much easier. However, not much work has been done with Atmos in the GitLab ecosystem, so documentation might be a bit scarce. But in the long run, I believe it will make scaling much smoother.

Just my two cents. Feel free to DM me if you want to chat more!

In that module, check line 191 in context.tf. the label order variable lets you define what gets included in the id attribute

It uses a different null label for it.

https://github.com/cloudposse/terraform-aws-eks-iam-role/blob/a217e963b61d3a05f2963c529bd18eb9c9d04fda/main.tf#L10

You could technically override the order to remove the attributes, however, you’d be impacting both the policy name and the iam role name