#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

Bump this question. @Abhigya Wangoo did you have success with any of the tools? Anyone else tried no-code / LLM based IaC tools with success? Is there a tool allowing for running on own infra with own LLM?

@Paweł Rein how much GPU RAM do you have available for LLM-based tools? do you mean running it on your laptop? or on a self-hosted cloud gpu?

I’m planning on experimenting with vLLM on EKS. Didn’t yet think of how much resources I can allocate

for Stakpak, code generation specifically uses 70B parameter model + a mix of techniques to beat GPT4-o1 performance on generating/modifying Terraform code (this involves things like documentation RAG, output validation with resource schema, and grammar bounded generation, an example comparison here)

the 70B parameter model at full precision ( FP 16 ) requires 140 GB of GPU RAM (70 billion * 2 bytes in gigabytes) the 70B parameter model at half precision ( FP 8 ) requires 70 GB of GPU RAM (70 billion * 1 byte in gigabytes)

to give you an idea of how much resources is required

I can help your team self-host it if you’re interested in running this on-prem, but some features like doc generation uses GPT4 we haven’t evaluated the performance of open weight models on doc generation yet

Thanks! I’ll talk to the team, now that I know the requirements. Stakpak looks really good, at least from the videos on your channel.

What I think could address the security need to not to have to run it on premise: some way to “anonimize” the imported infra (redact names, ids) before it leaves my git and de-anonymize it back when retrieved to my git as a PR. So that in case of a leak of our infra code the risk is limited. Would it be something you would be willing to maintain as an additional tool? I imagine it would be stateful. Not sure but maybe GHA or GH App could do, with state in GH?

We use a Stakpak GitHub app to create PRs. Stakpak however needs to see your code to to index it and pass it to LLMs so that it can help you make changes or add stuff.

Having access to the code/configurations also allow you to edit code in Stakpak, edit AI recommendations etc… before persisting changes in a PR.

The code itself however is transferred over TLS and stored encrypted on disk (like how you’d secure any kind of sensitive user data). We’re also working on getting SOC2 to make it easier for people to trust us. but I know eventually some people would still want to self-host it.

on another note, we don’t show one user’s private code to other users, and we don’t train LLMs on customer data.

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!

Our biggest regret was relying on GitLab’s managed state, which became a bottleneck when we moved to a polyrepo pattern for our microservices. Hey @Michael could you elaborate on why this became a bottleneck? I’m actually really liking the feature since you do not have to think about where to host the state and the integrated permission management. I use it for personal projects, however not (yet) at scale so I’m curious what you found out.

It’s super easy to setup and simple to use, but when you begin to scale it at an enterprise level, a few things become apparent:

The statefile is protected by the same permissions GitLab uses, so everyone with maintainer access will be able to access the state. This also comes into play when you need to use remote state, because the user will need read access to utilize that feature which could lead to over provisioning of permissions. Other backend typically offer more granular access controls.

We also found remote state operations to be cumbersome across a large org and that the development cycle was longer because our changes needed to be pushed to the pipeline to actually test the code

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

I’m trying to keep the tagging that [context.tf](http://context.tf) provides but override the name entirely. I want to provide a totally custom string irrelevant to the label order.

Understood. This is why you’d have to contribute a change to the specific null label module to get the intended effect.

See these code blocks

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

module "service_account_label" {
  source  = "cloudposse/label/null"
  version = "0.25.0"

  # To remain consistent with our other modules, the service account name goes after
  # user-supplied attributes, not before.
  attributes = [local.service_account_id]

  # The standard module does not allow @ but we want it
  regex_replace_chars = "/[^-a-zA-Z0-9@_]/"
  id_length_limit     = 64

  context = module.this.context
}

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

resource "aws_iam_policy" "service_account" {
  count       = local.iam_policy_enabled ? 1 : 0
  name        = module.service_account_label.id

You could expose a new input for the policy name perhaps

or you can avoid passing in the aws_iam_policy_document to disable the creation of the policy.

Then you can create the policy and attach it from outside of the module.

A few other designs if you’re interested in the topic

• https://github.com/gruntwork-io/terragrunt/pull/2403

• https://blog.fensak.io/terraform-compiler-pattern-79c7629e317e

It would be great to hear about experiences from someone who tried for example Terramate and Cisco Stacks

@Andriy Knysh (Cloud Posse)

Yea, pretty awesome!

@Igor Rodionov @Ben Smith (Cloud Posse) @Jeremy White (Cloud Posse)

I believe the relevant issue is here: https://github.com/hashicorp/terraform/issues/30841

For what it’s worth, there’s two ways I could think of right off the bat…

• put all these users in a separate root module and run that with parallelism of 1

• if you use atmos, you can just make instances of the users as components, then have a workflow that runs over all of them

it would likely be heavy handed to set up atmos just for this one scenario, but if you already have atmos set up, then it’s not as hard

one thing that surprises me, I haven’t heard anyone complain about our component that implements this using a module instance per user

https://github.com/cloudposse/terraform-aws-components/tree/main/modules/aurora-postgres-resources

Interesting, I will have a look at your module and compare. Also using the module option in a different place should have thought of that instead of looping over the var.

^ I’ve ran that before and not hit that error. Some discrepancies to keep in mind:

• the component is for ‘aurora’, but basically just uses the postgresql provider (the aws provider saves secrets to ssm)

• the component does a lot of smaller operations per user on those modules, so likely there’s less of a chance that things happen concurrently

I hope that helps out

Me too, I will let you know when I get a change to test it out.

you could likely just take our component module and strip out the ssm/iam resources so you could try it on any postgresql backend

but this is a long-standing complaint against terraform. If not postgresql users, folks also complain about ip assignment and other resources that are integral to devops

It’s little comfort to know it’s not a me issue, but something everyone suffers with..

@Jeremy G (Cloud Posse)

@Chris M Thank you for the PR.

We like to keep changes minimal, especially to the UserData, so that people running automatic upgrades to not get their ~clusters~ode groups rebuilt. Please try this PR and see if it solves your issue: https://github.com/cloudposse/terraform-aws-eks-node-group/pull/200

Guessing you mean node group would be rebuilt rather than cluster. I’ll give that change a go in a bit and see which bits of my original PR still stand

@Chris M My intention is to replace your PR with #200. This is a highly used module and I want to be as conservative as is reasonable when it comes to making changes.

PR 200 released as v3.1.1

I was hunting around for the cp module terraform docs config and tripped over the above

@Dan Miller (Cloud Posse) @Igor Rodionov

@Dan Miller (Cloud Posse) knows better

Is this feature planned to roll out to the cp modules soon ? Yes but it’s deep in the backlog; I would not say soon. Recently we’ve just started the process of migrating components to a dedicated github organization, each with their own repo. We’ll likely do something similar with terraform-docs there and then eventually roll it out to modules. But it will likely be several months out

this feels similar to the S3 api changes

similar, yes! and would have been so nice then to have this kind of refactoring capability.

yes, it was painful to do the s3 changes

@Jeremy G (Cloud Posse)

Same feature request for opentofu…. https://github.com/opentofu/opentofu/issues/2034

Found in logs…

module.codebuild_deploy.aws_codebuild_project.default[0]: Creation complete after 9s","@module":"terraform.ui","@timestamp":"2024-09-27T16:27:10.422760Z"

aws_iam_role_policy_attachment.codebuild[0]: Creating...","@module":"terraform.ui","@timestamp":"2024-09-27T16:27:10.666361Z"

codepipeline.aws_codepipeline.ecs_pipeline: Creating...","@module":"terraform.ui","@timestamp":"2024-09-27T16:27:20.952451Z"

So an eventual consistency problem… Guess im implementing a sleep command.

@Andrew Chemis do you still need support here?

No, I’ve resorted to a hacky work-around that mostly solves the problem at hand. I could open a bug on the underlying cloudposse module as it likely is impacting other people, but my solution is not ideal

Can you customize the prompt?

How are the LLMs installed?

Ooh, I like the idea of adding dynamic prompt support. The LLMs are a prerequisite, so if you have Ollama installed locally (brew install ollama), you can simply provide the model name and it’s good to go. I wrote a little getting started guide on how to customize the LLM prompt to get stronger recommendations