#terraform (2021-08)

https://www.terraform.io/docs/language/expressions/types.html#maps-objects

damn you are good sir! thank you! I’ve come up with a workaround but this is much cleaner. My workaround was:

  integrations = {
    for lambda in module.lambdas : lambda.function_name_iterator => {
      lambda_arn             = lambda.lambda_function_arn
      payload_format_version = "2.0"
      timeout_milliseconds   = 12000
    }
  }

i had to export a “fake” variable from my module where i added the “ANY /” in front of the function name

you can add/format any prefix/suffix/variable to (integrations.values.lambda_function_name) , it’s a standard terraform interpolation

I don’t believe you can currently loop with a for_each for provider aliases due to it being a meta-argument but you can consume the module you’re talking of like so:

module "waf_rules_euc1" {
  source = "./modules/waf-rules"

  providers = {
    aws = aws.eu-central-1
  }

  myvar = "value"
}

• repeat for regions

anyone can create a PR to add features/flexibility

there is not roadmap for features in community modules

although the cache behavior have variables and a dynamic already so seems to be pretty flexible

Oh, alright. Thanks @jose.amengual

They’re basically CloudPosse’s modules.

@Grubhold the error you’re getting spells it out — When ES is deployed it needs a certain number of subnets to account for the number of nodes that it has.

So for —

  dynamic "vpc_options" {
    for_each = var.vpc_enabled ? [true] : []
    content {
      security_group_ids = [join("", aws_security_group.default.*.id)]
      subnet_ids         = var.subnet_ids
    }
  }

Your var.subnet_ids needs to include more subnet IDs.

Thank you so much @Matt Gowie for pointing that out, it’s interesting not to notice this for a whole day

No problem — Glad that worked out for ya.

I believe @Jeremy G (Cloud Posse) recently updated that documentation… There was a big re-work he just did to support the 2.x k8s provider I’m pretty sure. Easy for something to pass through the cracks.

You may look for his PR (which should be recent) and see what changed to try and figure out the answer to this one.

PR to correct would be much appreciated!

I can only guess which one is correct (exec method), but as both statements have been added in the same PR, it’s not obvious which one is more true. I’m also a bit hesitant to start working on a PR because there seems to be some tooling involved in the readme file creation.

https://github.com/cloudposse/terraform-aws-eks-cluster/commit/51ccc3e90a4e417ed35e289627bce9e53ca9d50c#diff-b335630551682c1[…]f87428ed5106870f5R100

Ah that is indeed confusing then…

Since Jeremy isn’t around… @Andriy Knysh (Cloud Posse) do you know which of the two options Jeremy meant as the recommended way forward?

I would imagine it’s exec, but now I’m confused considering they’re both mentioned in the same PR.

@Ben @Matt Gowie The README needs revision, as you note. Please read the updated Release Notes for v0.42.0. Fixing the README will take a PR, but I was able to update the Release Notes easily.

Good stuff — Thanks Jeremy.

The short answer is “use data_auth if you can, kubeconfig for importing things into Terraform state, and exec_auth if it works and data_auth doesn’t.”

Great, thank you!

My security group module taken from CloudPosse’s

After making var.security_group_enabled as false that error went away.

But this time it gave me this error

use attribute and add diff attributes for the Elasticsearch and other modules you use with it

the issue is that all modules, when provided with the same context (e.g. namespace, environment, stage, name), generates the same names for the SGs that they create

adding attributes will make all generated IDs different

Oh wow, indeed all contexts in all module folders are the same. And I just found out that var.attributes are left without reference in [variables.tf](http://variables.tf)

many modules have flags to create the SG or not, you can create your own and provide to the modules

I wanted to use CP’s Security Group module as well for everything. But I think maybe for the time being I can just use my own simple security group configs instead of CP’s until I get to fully understand how its functioning.

And provide it to the modules as you say

cc: @Jeremy G (Cloud Posse)

@Erik Osterman (Cloud Posse) nothing really to do with our SG module, more, as Andriy said, about how we handle naming of SGs.

If I understood correctly you’re suggesting to use my own custom SGs but maybe follow the naming conventions you have set up in your SGs?

Also, thank you so much for sparing time to answer my rather newbie questions. But I’m loving your modules and it has been teaching me a lot!

@Gerald — If you’ve got the code then put it up on PR and mention it in #pr-reviews. We’d be happy to take a look at it.

Thanks Matt will do it

Sounds like a potential bug in the module? PR to fix would be welcome!

Should be there already, horribly done. But there

https://github.com/cloudposse/terraform-aws-ec2-instance-group/pull/32

Do it entirely by hand and then remediate your TF state after. I’m mostly serious. Terraform is not good at changing state in a sensible way

^ that’s how I have usually done DB upgrades

There is a flag to do an immediate apply but if the upgrade takes a while then I imagine the odds of Terraform timing out are high

It’s not in terraform, but I really liked this article… https://engineering.theblueground.com/blog/zero-downtime-postgres-migration-done-right/

ugh I could have really used that a month ago

@Eric Alford I’m assuming you just need the ability to associate additional domains with that SES sender? That seems like an easy one to wire in a new variable for. You can give it a shot and put up a PR and we’ll be happy to take a look at it.

just post your PR in #pr-reviews and it will get more

Depends on whether you’re attaching EC2 (ASG), ECS, or lambdas

EC2 ASG for example - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_attachment

ECS its done in the ECS Service Definition itself in the load_balancer block https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service

Just with EC2

https://twitter.com/mazen160/status/1423656302375575553

Do you have a link to the stream?

@Alex Jurkiewicz it was livestreamed yesterday, here is the recorded talk: https://www.youtube.com/watch?v=3ODhxYY9-9U

whoot! will share on office hours

Not really much to go on here… does that plan indicate what is causing it to recreate? my guess is it’s not the version change.

It is the version change. If upgrading cluster from Aws Console and allowing it to propagate to the individual instances, then changing the passed in version in the terraform stack - it detects the remote changes and is happy.

I can provide more details when I have time to revisit.

looks like @RB already approved and merged

what does monorepo have to do with the state migration?

Someone linked https://github.com/minamijoyo/tfmigrate recently, which seems good for more complex migrations

Additional note: the Launch template it generates seems ok when I specify a subnet for it. I am passing in a list of 3 subnets for my 3 AZs.

The modules …

module "datadog_integration_alpha_prod" {
  source  = "cloudposse/datadog-integration/aws"
  version = "0.13.0"

  namespace    = "alpha"
  stage        = "prod"
  name         = "datadog"
  integrations = ["all"]

  forwarder_rds_enabled        = true

  dd_api_key_source = {
    identifier = aws_ssm_parameter.dd_api_key_secret.name
    resource = "ssm"
  }

  providers = {
    aws = aws.alpha-prod
  }
}

module "datadog_integration_alpha_stg" {
  source  = "cloudposse/datadog-integration/aws"
  version = "0.13.0"

  namespace    = "alpha"
  stage        = "stg"
  name         = "datadog"
  integrations = ["all"]

  forwarder_rds_enabled        = true

  dd_api_key_source = {
    identifier = aws_ssm_parameter.dd_api_key_secret.name
    resource = "ssm"
  }

  providers = {
    aws = aws.alpha-stg
  }
}

The errors…

 Error: failed to execute "git": fatal: not a git repository (or any of the parent directories): .git
│ 
│ 
│   with module.datadog_integration_alpha_stg.module.forwarder_rds[0].data.external.git[0],
│   on .terraform/modules/datadog_integration_alpha_stg.forwarder_rds/main.tf line 7, in data "external" "git":
│    7: data "external" "git" {
│ 

Tony, please set forwarder_rds_enabled = false

and try again

These both succeed if we set the forwarder_rds_enabled to false, but the whole reason we’re using this is that we want to enable enhanced RDS info being forwarded to DataDog

we are moving all that code out of it and we are creating a module just for the DD forwarder

I’m pretty sure it will be released today

although the error you are getting is related to git not able to pull the datadog repo

you should be able to download this : <https://raw.githubusercontent.com/DataDog/datadog-serverless-functions/master/aws/rds_enhanced_monitoring/lambda_function.py?ref=3.34.0>

although the error you are getting is related to git not able to pull the datadog repo Yeah, it appears so. This is running from TF cloud though, and only an issue with this module. Other changes in our workspace are working fine, as does this module with the enhanced RDS functionality turned off.

I’ll look for that new module. Do you have a link to the repo?

the repo is private until re lease it

I will send you the link when is ready

but that functionality on how we download the file has not been changed

so I imagine you will have the same issue

Am I missing anything in my module block?

Could the providers blocks be causing an issue?

this are the providers needed

terraform {
  required_version = ">= 0.13"

  required_providers {
    # Update these to reflect the actual requirements of your module
    local = {
      source  = "hashicorp/local"
      version = ">= 1.2"
    }
    random = {
      source  = "hashicorp/random"
      version = ">= 2.2"
    }
    aws = {
      source  = "hashicorp/aws"
      version = ">= 3.0"
    }
    archive = {
      source  = "hashicorp/archive"
      version = ">= 2.2.0"
    }
  }
}

the archive module is trying to do this :

is trying to run git on that file

it could be that where are you running it git is not properly configured

Perhaps, but we’re running it in TF Cloud. I’ll try planning from my workstation later this evening and report back.

ohhh tf cloud, that might be an issue

yeah

Other cloudposse modules haven’t been an issue so far, we’ve had success with them in TF Cloud

no many modules use the git pull strategy

@Tony Bower https://github.com/cloudposse/terraform-aws-datadog-lambda-forwarder we just released it

you will see in the example how to use a local file so in the case of running in TFC then you can push the code in your repo and use the local file instead

Thanks! I’ll give it a shot tonight! Thanks for updating the thread.

np, let me know how that goes, I can make changes to the module since I’m still working on it so any feedback is appreciated

you will see in the example how to use a local file so in the case of running in TFC then you can push the code in your repo and use the local file instead I’m not sure I follow what you are suggesting here.

so the problem you had with the RDS forwarder in Terraform cloud

was I think related to the module trying to run git

so with this new module you can point to a local file instead

Ok, I didn’t find that in the example, so maybe I missed it or wasn’t sure.

that was if you are running in a system where remote url connections are not allowed ( like TFC) then you can use a local zip file with the code

sorry, in the readme :

module "datadog_lambda_forwarder" {
  source = "cloudposse/datadog-lambda-forwarder/aws"
  forwarder_log_enabled = true
  forwarder_rds_artifact_url = "${file("${path.module}/function.zip")}"
  cloudwatch_forwarder_log_groups = {
    postgres =  "/aws/rds/cluster/pg-main/postgresql"
}

Ah, ok! Thanks!

have you read https://www.terraform.io/docs/cloud/workspaces/state.html#state-manipulation ?

you will have to go one by one

first update to 0.13 .. it comes with a command that update the tf files to new format .. a minor refactoring will be required but it can be done.

after upgrading .. the next time you will do terraform plan .. it will upgrade automatically

fixed, was using an older version of aws provider. Upgraded to 3.53.0 and it works flawlessly

Looks like we should set a minimum version for the module

it’s because the number of ARNS depends on a computed value

I guess you are passing in a ARN that is dynamically generated in the same terraform configuration

in this case, Terraform doesn’t know what the length of var.privileged_principal_arns is at plan time, so it doesn’t know how many resources of resource "aws_s3_bucket_policy" "default" to create

jupp I pass the arn in via from a ECS module. Ok then instead of checking the length would it make sense to check != "" or != null?

what confuses me, is that if I am trying this one out in a test repo where I just call the module with some random string as ARN it works

Right. Because the string is hard coded

added a PR: https://github.com/cloudposse/terraform-aws-s3-bucket/pull/103 and Issue: https://github.com/cloudposse/terraform-aws-s3-bucket/issues/102 Feel free to have a look

do you mean https://github.com/bridgecrewio/yor?

man! i just found it too and was going to post

thanks, that’s it

If it can be done with the aws cli, then there is an api for it, which means terraform could do it also… If it doesn’t have the feature yet, check for an existing issue or open one!

https://github.com/prometheus/cloudwatch_exporter

only when the object doesn’t exist in the account

hmm, i can see it via the console, I’ll get the cli

ah, typo

Sorry, this is overly broad. What have you already tried? Have you successfully created one VPN connection? Are you getting any errors?

I think one of the benefits of using driftctl is that it can detect resources that are deployed in the cloud but not managed through Terraform.

At least that’s the promise.

Spacelift drift detection will detect (and optionally fix) drift only against the resources it manages.

So in that sense you can use both, though each for a different reason.

Good point. So it’s not so much drift as “unmanaged resources”. I’m curious how many people try to map out unmanaged resources and for what reason. For example, as a security person, I’d want to know if there are security issues in unmanaged resources. But I’m wondering if Engineering leaders care about them as much.

There are also tools like https://steampipe.io/ or https://www.cloudquery.io/ that allow you to query entire accounts for possible security violations regardless of how resources are managed.

¯_(ツ)_/¯

Oh, there are dozens, if not hundreds of tools for that. But one could say that the approach to security in IaC (like what we do at Cloudrail, or Bridgecrew/Accurics/Fugue does), is different to security in unmanaged resources.

are you sure is finding the subnet and vpc?

did you see them in the plan?

yep - they are already created.

In fact, this is the plan in question:

(venv) andylamp@ubuntu-vm:~/Desktop/my-tf$ tf plan
module.vpc-dev.module.my-vpc.aws_vpc.this[0]: Refreshing state... [id=vpc-00337c2afe6fce5c3]
module.vpc-dev.module.my-vpc.aws_eip.nat[0]: Refreshing state... [id=eipalloc-012856d4a1d951283]
module.vpc-dev.module.my-vpc.aws_subnet.private[2]: Refreshing state... [id=subnet-08266fec0283b0297]
module.vpc-dev.module.my-vpc.aws_subnet.private[0]: Refreshing state... [id=subnet-0325a36af25038e1c]
module.vpc-dev.module.my-vpc.aws_subnet.private[1]: Refreshing state... [id=subnet-0d55505e94c067aa2]
module.vpc-dev.module.my-vpc.aws_route_table.public[0]: Refreshing state... [id=rtb-0d42a5eb7d09ee795]
module.vpc-dev.module.my-vpc.aws_internet_gateway.this[0]: Refreshing state... [id=igw-005edae1c9ed3fa6b]
module.vpc-dev.module.my-vpc.aws_subnet.public[0]: Refreshing state... [id=subnet-0975f87892ab81275]
module.vpc-dev.module.my-vpc.aws_subnet.public[2]: Refreshing state... [id=subnet-0f148b639a32bc4d0]
module.vpc-dev.module.my-vpc.aws_subnet.public[1]: Refreshing state... [id=subnet-05611d5e681c8ff3c]
module.vpc-dev.module.my-vpc.aws_route_table.private[0]: Refreshing state... [id=rtb-04a14b9c331a1298a]
module.vpc-dev.module.my-vpc.aws_route.public_internet_gateway[0]: Refreshing state... [id=r-rtb-0d42a5eb7d09ee7951080289494]
module.vpc-dev.module.my-vpc.aws_nat_gateway.this[0]: Refreshing state... [id=nat-05b7e44d3b553b476]
module.vpc-dev.module.my-vpc.aws_route_table_association.public[0]: Refreshing state... [id=rtbassoc-0f540546824c3129d]
module.vpc-dev.module.my-vpc.aws_route_table_association.private[1]: Refreshing state... [id=rtbassoc-033f6fc6e37b040e8]
module.vpc-dev.module.my-vpc.aws_route_table_association.public[1]: Refreshing state... [id=rtbassoc-08deab663c8d993d9]
module.vpc-dev.module.my-vpc.aws_route_table_association.public[2]: Refreshing state... [id=rtbassoc-08d46742cd13a384d]
module.vpc-dev.module.my-vpc.aws_route_table_association.private[0]: Refreshing state... [id=rtbassoc-045d114f50647d8a6]
module.vpc-dev.module.my-vpc.aws_route_table_association.private[2]: Refreshing state... [id=rtbassoc-011e95d58db228e53]
module.vpc-dev.module.my-vpc.aws_default_network_acl.this[0]: Refreshing state... [id=acl-01bbf32f28ecd8ea9]
module.vpc-dev.module.my-vpc.aws_route.private_nat_gateway[0]: Refreshing state... [id=r-rtb-04a14b9c331a1298a1080289494]
╷
│ Error: Invalid count argument
│ 
│   on .terraform/modules/my-redis-cluster.redis/main.tf line 31, in resource "aws_elasticache_subnet_group" "default":
│   31:   count      = module.this.enabled && var.elasticache_subnet_group_name == "" && length(var.subnets) > 0 ? 1 : 0
│ 
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use
│ the -target argument to first apply only the resources that the count depends on.

did you set the var.elasticache_subnet_group_name ?

no wait

I was under the impression that this was not needed

https://github.com/cloudposse/terraform-aws-elasticache-redis/blob/master/examples/complete/main.tf#L28

followed this bit.

var.subnets I think is basically 0

module.subnets.private_subnet_ids is a list

are you passing a list of subnets?

yes, the private ones.

what essentially I get from the output of this:

# grab the private subnets within the provided VPC
data "aws_subnet_ids" "vpc-private-subs" {
  vpc_id     = data.aws_vpc.redis-vpc.id
  depends_on = [data.aws_vpc.redis-vpc]
  tags = {
    Name = "*private*"
  }
}

which is a list of subnets.

matching to that tag.

as per here: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/subnet_ids

(btw, thanks for replying fast!)

how does the module initialization looks like?

sec - let me fetch that.

basically this - and then I call it in my [main.tf](http://main.tf) as:

module "my-redis-cluster" {
  source = "./modules/my-ec-redis"
  vpc_id = data.aws_vpc.vpc-dev.id
}

(the data bits are in the [variables.tf](http://variables.tf) of the my-ec-redis module)

try passing a hardcoded subnet id to the subnets =

so, with [] (which assumes hardcoded) it works.

like subnets = [ "subnet-0325a36af25038e1c"]

I think this works, it just does not like when I dynamically fetch it from the target vpc

I think this is a bit weird

tell me about it

you have a module creating the vpc, then you do a data lookup to look at stuff the vpc module created

yep

and plus you tell the data resouce it depends on the module

exactly.

cyclical dependency

so use the output of the module.vpc-dev and output the subnet ids

and use the output as input for the redis module

TF will know how to build the dependency from that relationship

right, gotcha

let me try this.

when you start using depends_on you can make TF confused

cool, let me try this and hopefully this works - thanks for the tip!

(if not, I’ll just ping here again )

seems to be able to plan it now, I am curious however why this did not happen with aws eb resource (aws_elastic_beanstalk_environment) there I seem to be passing them as such:

  setting {
    name      = "Subnets"
    namespace = "aws:ec2:vpc"
    value     = join(",", data.aws_subnet_ids.vpc-public-subnets.ids)
    resource  = ""
  }

It is able to both find them and use them successfully - if it was a circular dependency, then surely it would be a problem there as well right?

but there is no depends_on

there is

so it can calculate the graph dependency

and this is how the my-eb module is defined:

# now create the app
resource "aws_elastic_beanstalk_application" "eb-app" {
  name = var.app_name
}

# configure the ELB environment for the target app
resource "aws_elastic_beanstalk_environment" "eb-env" {
  application         = aws_elastic_beanstalk_application.eb-app.name
  name                = var.env_name
  solution_stack_name = var.solution_stack_name == null ? data.aws_elastic_beanstalk_solution_stack.python_stack.name : var.solution_stack_name
  tier                = var.tier


  # Configure various settings for the environment, they are grouped based on their scoped namespace

  # -- Configure namespace: "aws:ec2:vpc"

  setting {
    name      = "VPCId"
    namespace = "aws:ec2:vpc"
    value     = var.vpc_id
    resource  = ""
  }

  # associate the ELB environment with a public IP address
  setting {
    name      = "AssociatePublicIpAddress"
    namespace = "aws:ec2:vpc"
    value     = "True"
    resource  = ""
  }

  setting {
    name      = "Subnets"
    namespace = "aws:ec2:vpc"
    value     = join(",", data.aws_subnet_ids.vpc-public-subnets.ids)
    resource  = ""
  }
  
  // more properties...
 }

that will be because the count can be calculated

right, it does not use count

count or for_each can’t use values that can’t be calculated at plan time

otherwise how many will create then?

ok I see, that’s helpful to know.

you can sometimes do a local with a tenary that can calculate the value before hand

nice, do you happen to have an example that I can see of such a use case? I’d be really helpful.

no I was wrong sorry, the value needs to be calculated at compile time, I do not think is possible to do it otherwise

I was going to show you this : https://github.com/cloudposse/terraform-aws-ssm-patch-manager/blob/master/ssm_log_bucket.tf

where I had a logic to do that but it did not work and I had to change the count arguments because I was trying to use a data resource

if you apply once a data resource like when using target and then use them in the count then that will work I think but it adds a step that you do not need if you make your logic simpler

one of your inputs and as well a count argument is not determiable by terrafrom. I had the same Issue some days ago (https://sweetops.slack.com/archives/CB6GHNLG0/p1628844492126800) There is no workaround. Either hardcode the variable or create things by your own. I wasted 3 Days figuring this out

@jose.amengual thanks a lot for the clarification, I think hard-coded values is the way to go for now.

np

could you try this https://github.com/cloudposse/terraform-aws-s3-bucket/issues/102#issuecomment-906779848 ?

using this in terraform

data "template_file" "prom_template" {
  template = file("./templates/prometheus-values.yaml")
  vars = {
    GRAFANA_HOST = var.domain_name == "" ? "" : "grafana.${local.cluster_name}.${var.domain_name}"
    CLUSTER_REGION = var.app_region
    ASSUME_ROLE_ARN = aws_iam_role.cloudwatch_role.arn 
  }
}

resource "helm_release" "prometheus" {
  chart            = "kube-prometheus-stack"
  name             = "prometheus"
  namespace        = kubernetes_namespace.monitoring.metadata.0.name
  create_namespace = true
  version          = "17.1.1"

  repository = "<https://prometheus-community.github.io/helm-charts>"

  values = [
    data.template_file.prom_template.rendered
  ]
}

Then setup kubectl and installed the helm chart and after that port forwarded to see GUI but not able to see the cloudwatch data source

logging in from your pc to use awscli?

when you assume a role, you can set the expiry, the default is 1hr but you can go up to 8 generally

Oh ok it’s have security concerns…

Look into the refreshable credential in botocore, and the credential_process option in the awscli config. Between the two, you can have auto-refreshing temporary credentials

that’s all workarounds, you probably want to have AWS SSO configured for your account. its credentials are supported on aws-cli and terraform provider side. still you have to login from time to time once temporary credentials expire (this is configurable)

no thanks. AWS SSO is terribly limited when it comes to the full set of IAM features. sticking with Okta and an IAM Identity Provider for now

Checkout leapp.cloud. It handles automatic refreshes and provides best-in-class ui

https://www.leapp.cloud/

cc: @Andrea Cavagna

Both for AWS SSO and Okta Federated IAM Roles, Leapp store secure informations, such as AWS SSO token to generate credentials, and SAML response, in a secure place locally (EG. Keychain for MacOS) https://docs.leapp.cloud/contributing/system_vault/

And in the app the User can choose in which AWS Account log into Leapp generate and rotate temporary credentials.

If you have any question feel free to text me

I’ve been following leapp for a while, but haven’t yet given it a try

i can’t figure out the leapp setup when using okta. what role_arn? i have many roles through okta, and many accounts…

It’s the federated role arn with okta: Okta app add a federated role for each role in any account you have access to, you see is in the IAM Role panel https://docs.leapp.cloud/use-cases/aws_iam_role/#aws-iam-federated-role

If leapp is getting that info from Okta, why is it asking me for a role_arn in the setup?

Leapp is not getting this information from Okta, it’s up to you know what is the correct roleArn for a given IAM Role federated with okta

oh yeah, ok, no. this is too much setup for me. i’d have to add dozens of accounts and pick a single role for each one, or multiply by each role i wanted in Leapp

direct integration with okta would be a much nicer interface, similar to aws-okta-processor

The Okta application is always the same, you have just to add all the role arn you can access to. The integration with okta is in roadmap, I’ll keep you updated

not for multiple accounts, the idp arn changes also

ok thanks

i’ll be glad to try it again when Okta is supported directly as an IdP

i’m also curious if you had considered a credential_process integration via ~/.aws/config, instead of writing even the temp credential to ~/.aws/credentials?

Absolutely, Leapp will soon move the core business logic to a local Daemon that will comunicate with the UI. In the Daemon roadmap there is the credentials process written in the ~/.aws/config file: https://github.com/Noovolari/leapp-daemon/issues/20

we have an id length limit parameter i believe

cc: @Jeremy G (Cloud Posse)

Sorry, we know of no comprehensive list of ID length limits. We did consider adding some pre-configured length limits but gave up because (a) we could not find such a list and (b) to the extent we did find limits, they were all over the place.

all over the place. Agreed!

The null-label module that we use to generate all our ID fields does have a length limit field. If you find length limits on resource names, you can submit a PR or even just open an issue to set that length on the module that creates that resource.

Of course you can also use it directly.

@managedkaos https://github.com/cloudposse/terraform-null-label/#input_id_length_limit

yes you can do that

https://www.youtube.com/watch?v=V2b5F6jt6tQ

Excellent, thanks

it’s inside every module already

you don’t need to copy it if you are just using the modules

just provide the namespace, env, stage, name

Ok, that’s where I was confused I guess. Here’s an example of an example (heh) where I see it added.

https://github.com/cloudposse/terraform-aws-datadog-integration/tree/master/examples/rds-enhanced

those vars are inside [context.tf](http://context.tf)

the main purpose of the file is to provide common inputs to all modules w/o repeating them everywhere

(also, note, we’ve just released an updated version that adds some more fields)

Hello @Alencar Junior, if you store the personnal_access-token in an azure KeyVault, you can then read it securely with data.

data.azurerm_key_vault_secret.example.value

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/data-sources/key_vault_secret

Thanks @Pierre-Yves, I will try that.

Hi @Pierre-Yves, I’ve created a key vault secret and I am using a data resource in order to fetch its value to my service connection however, when I run the command terraform state pull I can see the personal_access_token value as a plain text, am I missing something?

when writting to azure key vault, you should set azurerm_key_vault_secret option to:

  content_type = "password"

variables should have the parameter “sensitive = true” https://learn.hashicorp.com/tutorials/terraform/sensitive-variables

Hi @Pierre-Yves, this is how I’m fetching the secrets:

data "azurerm_key_vault" "existing" {
  name                = "test-kv"
  resource_group_name = "test-rg"
}

data "azurerm_key_vault_secret" "github" {
  name         = "github-pat"
  key_vault_id = data.azurerm_key_vault.existing.id
}

resource "azuredevops_serviceendpoint_github" "serviceendpoint_ghes_1" {
  project_id            = data.azuredevops_project.project.id
  service_endpoint_name = "Test GitHub Personal Access Token"

  auth_personal {
    personal_access_token = data.azurerm_key_vault_secret.github.value
  }
}

I set the secret type as password however, it seems the secret value will be always stored in the raw state as plain-text.

This is what I get when running terraform state pull :

{
      "mode": "managed",
      "type": "azuredevops_serviceendpoint_github",
      "name": "serviceendpoint_ghes_1",
      "provider": "provider[\"<http://registry.terraform.io/microsoft/azuredevops\|registry.terraform.io/microsoft/azuredevops\>"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "auth_oauth": [],
            "auth_personal": [
              {
                "personal_access_token": "[PLAIN-TEXT-VALUE]",
                "personal_access_token_hash": "......"
              }
            ],
            "authorization": {
              "scheme": "Token"
            },
            "description": "Managed by Terraform",
            "id": "..........",
            "project_id": "........",
            "service_endpoint_name": "Test GitHub Personal Access Token",
            "timeouts": null
          },
          "sensitive_attributes": [
            [
              {
                "type": "get_attr",
                "value": "auth_personal"
              }
            ]
          ],

sorry I don’t have much more information on it, you might want to encrypt/decrypt your secrets you might have a look to rsadecrypt function and encryption

That might be the way. Thanks for the help, I really appreciate it!

only if you’re using terragrunt

well then

we “should be able to” but terraform doesn’t let us

Part of it is the module is cached during init, which doesn’t take vars, so the dereference needs to happen outside of TF

Ahhhhh yes, makes sense @loren

How do I provide it to this

Based on Foqal app’s suggestions it lead me to this page https://alto9.com/2020/05/21/aws-ssm-parameters-as-ecs-environment-variables/#comments

If I understand correctly I need to have this block for every variable that I want to pass in the container

variable "secrets" {
  type = list(object({
    name      = string
    valueFrom = string
  }))
  description = "The secrets to pass to the container. This is a list of maps"
  default     = null
}

For example this is the type of variables I have in .tfvars

directory_api_parameter_write = [
  {
    name        = "DB_PASSWORD"
    value       = "password"
    type        = "SecureString"
    overwrite   = "true"
    description = "Issuer Directory"
  },
  {
    name        = "DB_USER"
    value       = "sa"
    type        = "String"
    overwrite   = "true"
    description = "Issuer Directory"
  }
]

How do I structure it? Sorry I couldn’t find an example in the repos

SOLUTION for anyone interested this is how I did this.

1. Provide your secrets in a list in .tfvars for example

   directory_api_parameter_write = [
     {
    name        = "DB_PASSWORD"
    value       = "password"
    type        = "SecureString"
    overwrite   = "true"
    description = "Directory API"
     },
     {
    name        = "DB_USER"
    value       = "sa"
    type        = "String"
    overwrite   = "true"
    description = "Directory API"
     }
   ]
   

1. In [variables.tf](http://variables.tf) point to that

   variable "directory_api_parameter_write" {
     type        = list(map(string))
   }
   

1. Include this variable name in the task definition module calling as var.directory_api_parameter_write

but now the task def will have all your secrets in plain text

or are they showing up as secrets? the reason I point this out is because ECS now supports secrets arn mapping in the task Def but a year ago it did not

indeed it does. I don’t use a module for the task def, instead opting for a template. but mine is formatted like this:

... 
       "secrets": [
            {
                "name": "VARIABLE_NAME",
                "valueFrom": "arn:aws:ssm:${logs_region}:${account_id}:parameter/${name}/${environment}/VARIABLE_NAME"
            },
...
]

that is exactly what I was referring to @managedkaos

in the old day you needed to use something like chamber as an ENTRYPOINT to feed the ENV variables and such

@jose.amengual @managedkaos indeed they are now showing as plain text in the task definition page on AWS. And they’re not being treated as secrets or valueFrom but instead as value.

@managedkaos I can’t change it now at this point to template because I need to demo this in the upcoming week. I need to use CloudPosse’s module as its how everything is structured

What you suggest me do? The corresponding variables for these two is this

I tried passing this from .tfvars but terraform gives error that it doesn’t accept quotes in valueFrom and it gets invalid when I remove quotes

ClientException: The Systems Manager parameter name specified for secret TEST_DB_ENC_KEY is invalid. The parameter name can be up to 2048 characters and include the following letters and symbols: a-zA-Z0-9_.-,

@managedkaos @jose.amengual Really out of options I think that this should be very easy but I must be missing a big part. I got so used to CloudPosse’s modules and the structure and I want to use it, but very stuck at this point. Need your guidance

Also @managedkaos if a template is the best way to go, in that case I only need to include the template instead of the container_definitions part in the module? Can you please show me an example of the template file and it’s variables/tfvars how it’s being passed to the template?

system panager parameters are path+name like /myapp/servicea/mysecret

even if you have on layer is still /mysecret

and they need to exist before hand obviously

so the first time I’m actually writing the variables to parameter store I need to provide path? I actually went ahead and changed them to this. Is this correct?

But again it terraform yells at me with the new name

Error: ClientException: The Systems Manager parameter name specified for secret /opdev/issuer/DB_PASSWORD is invalid. The parameter name can be up to 2048 characters and include the following letters and symbols: a-zA-Z0-9_.-,

Is it something to do with how secrets is configured in the module itself?

no, you need name and value

name is just the name that will. end up as an env var

the value from is the arn of the secret I believe

I have an example but I’m not in my computer

@jose.amengual I think I got somewhere with your comment. So I took the arn output of SSM

issuer_parameter_write = [
  {
    name        = "/opdev/issuer/DB_ENC_KEY"
    value       = "secretkey123"
    type        = "SecureString"
  },

And added it to the secrets variable that is being passed to the container definition as such

issuer_secrets = [
  {
    name      : "/dk/ssi_api/DB_ENC_KEY"
    valueFrom : "arn:aws:ssm:eu-west-1:1111123213123:parameter/opdev/issuer/DB_ENC_KEY"
  }
]

On the AWS Task Definition UI it is now showing the arn instead of the plain text value itself.

It no longer gave me that notorious error! it just yelled at me saying that

The secret name must be unique and not shared with any new or existing environment variables set on the container, such as '/opdev/issuer/DB_ENC_KEY'

And thats because I have already registered that var with that name on SSM using that parameter_write for the SSM module

But I wouldn’t know the arn if I haven’t created it first. For the sake of automation I will need to create maybe a function to take the arn outputs and pass to the consumer module. What you suggest @jose.amengual the output currently is this

name_list = tolist([
  "/opdev/issuer/DB_ENC_KEY",
  "/opdev/issuer/DB_SIG_KEY",
  "/opdev/issuer//NODE_CONFIG_DIR",
  "/opdev/issuer/NODE_CONFIG_ENV",
])
ssm-arn = tomap({
  "/opdev/issuer/DB_ENC_KEY" = "arn:aws:ssm:eu-west-1:111112312312:parameter/opdev/issuer/DB_ENC_KEY"
  "/opdev/issuer/DB_SIG_KEY" = "arn:aws:ssm:eu-west-1:111112312312:parameter/opdev/issuer/DB_SIG_KEY"
  "/opdev/issuer/NODE_CONFIG_DIR" = "arn:aws:ssm:eu-west-1:111112312312:parameter/opdev/issuer/NODE_CONFIG_DIR"
  "/opdev/issuer/NODE_CONFIG_ENV" = "arn:aws:ssm:eu-west-1:111112312312:parameter/opdev/issuer/NODE_CONFIG_ENV"
})

Possible Solution added a new function called as arn_list_map to [outputs.tf](http://outputs.tf) to combine name_list and arn_list in ssm-parameter-store module

# Splitting and joining, and then compacting a list to get a normalised list
locals {
  name_list = compact(concat(keys(local.parameter_write), var.parameter_read))

  value_list = compact(
    concat(
      [for p in aws_ssm_parameter.default : p.value], data.aws_ssm_parameter.read.*.value
    )
  )

  arn_list = compact(
    concat(
      [for p in aws_ssm_parameter.default : p.arn], data.aws_ssm_parameter.read.*.arn
    )
  )

  # Combining name_list and arn_list and mapping them together to produce output as a single object.
  arn_list_map = [
  for k, v in zipmap(local.name_list, local.arn_list) : {
    name  = k
    valueFrom = v
  }
  ]
}

output "names" {
  # Names are not sensitive
  value       = local.name_list
  description = "A list of all of the parameter names"
}

output "values" {
  description = "A list of all of the parameter values"
  value       = local.value_list
  sensitive   = true
}

output "map" {
  description = "A map of the names and values created"
  value       = zipmap(local.name_list, local.value_list)
  sensitive   = true
}

output "arn_map" {
  description = "A map of the names and ARNs created"
  value       = zipmap(local.name_list, local.arn_list)
}

output "arn_list" {
  description = "Key and valueFrom map list"
  value = local.arn_list_map
}

So this will actually produce a list of objects where you can just point it in the task definition module. Taking the arns directly from parameter_write

so my container def have this :

"secrets": [
      {
        "valueFrom": "${db_secret_arn}:password::",
        "name": "DATABASE_PASSWORD"
      },

then :

data "template_file" "server_task_definition" {
  template = file("${path.module}/templates/container_definition_ossindex_server.json")

  vars = {
    db_secret_arn                = data.aws_secretsmanager_secret.db_info.arn
}
}

and on the module :

module "ecs_alb_service_task_index_server" {
  source                             = "git::<https://github.com/cloudposse/terraform-aws-ecs-alb-service-task.git?ref=0.35.0>"
  name                               = var.name
  namespace                          = var.namespace
  stage                              = var.environment
  attributes                         = var.attributes
  container_definition_json          = data.template_file.server_task_definition.rendered
...

that is how I use it, if you use the container_definition module is just a different input format but the output is the same

@jose.amengual Thanks for the examples

Wish they would add it generically for all resources. Eg finding a bucket by regex

How’s your Go skills? You can open a PR too like this person did

The one I opened almost a year ago is not merged, seems like a poor ROI

I was working on one and gave up on it at some point: https://github.com/hashicorp/terraform-provider-aws/pull/16989

For that purpose, we have https://github.com/cloudposse/terraform-aws-named-subnets

But honestly, I would avoid the strategy of allocating subnet ranges this way. It makes it very rigid and if you’re operating in lots of accounts, difficult to scale. We typically use security groups for isolation, not networks.

The only place where I’ve found more specialized CIDRs being useful, is on AWS Client VPNs, to map user’s memberOf attribute to whitelisted CIDRs

Recently I had to delete a subnet that was used in an RDS subnet group. It is a big hassle and problem moving an RDS instance from one subnet group to another. Thats why the idea was to have one subnet group only for one RDS Instance to make services like RDS and their networks independent from each other so that in the future when i want to do something with one service and it’s network, it does not impact other services.

@Erik Osterman (Cloud Posse) could you elaborate a bit more on rigidity and multiple accounts?

Have a look at https://github.com/cloudposse/terraform-aws-components/tree/all-new-components

This branch is much more up-to-date (yet still outdated, I believe).

thanks! could you tell me how to specify a branch in vendir?

ref: 0.140.0

can be a tag or a branch so you could use

ref: all-new-components

My information on the branch is a couple months old, so maybe someone from Cloudposse wants to chime in and tell me if I’m wrong. (it works for me though).

damn it does not support TF 1.0

You mean this https://www.terraform.io/docs/language/functions/regex.html?

You can use something like regex(".*latest.*", var)

i can’t spell regex

i had rege()

The big question is what is the plural of regex?

if that had been rage() i would have understood

based off the last two weeks I wouldn’t be surprised if i wrote rage

https://twitter.com/ifosteve/status/1190348262500421634?lang=en

@Yoni Leitersdorf (Indeni Cloudrail) your regex proposal didn’t seem to work unless I have done it wrong

Can you post the code?

I’m on my phone so can’t test it right now, but look at how they use regex here: https://www.terraform.io/docs/language/values/variables.html#custom-validation-rules

They use the singular function, not regexall, and wrap it with can for the true. You want latest not to be in there so you’d need to check that can is false

@Steve Wade (swade1987) did it work for you?

Nope I couldn’t get it working and it was like midnight local time so just left it

I tried a few attempts

are the instances and redis on the same subnet?

is the SG of redis allowing the subnet?

are they in the same VPC

many things to check

“are the instances and redis on the same subnet?” the subnet group of the redis contains the subnet of the ec2

“is the SG of redis allowing the subnet?” im not sure I understand, they are both on the same VPC. the security group allows ingress from the default sg of the VPC

then the default sg is applied to the instance security groups

i think it has to do with the security groups because i can open the SG up to all traffic from anwyhere and it still doesn’t connect

the ping the redis endpoint and compare the ip subnet with the instance ip

maybe is in a public subnet

for the sake of testing, im going to recreate the redis only on public subnet which the ec2 is on

i figure the ec2 and redis need to be on the same subnet?

yes

it is highly NOT recommended to have redis on a public subnet

you should move your instance tot eh private subnet

put an ALB on front or something to reach it

if i move ec2 to a private subnet then i cant ssh into it

im doing this just to test connectivity

you can use SSM Session manager or Instance connect

you need the help of someone on the Networking department, you could put everything in the public subnet but it will expose it to the internet which is not recommended

i seemed to messed up all my stuff now

so i gotta start over

i would not put redis on public subnet normally

if it is on a public subnet on a vpc with an igw, should i be able to access from my local machine?

yes

but keep in mind it is exposed to the internet

it didn’t used to be that way

ok .. i have no idea. i made it totally public.. can’t even ping it

sg allows all traffic from my IP

its on public subnets

this is becoming senseless

you need guidance from someone with networking knowledge, there is some basic concepts you are missing that you need to understand before you can get this to work

i mean i can get literally any other service to work in this same manner, vpc with nat and igw, public subnets associated to service, secureity group allowing ingress

before elasticache was in no way accessible from outside the vpc

but lets just suppose i use the example on that tf package

any service on the same vpc with that sg attached should be able to access it

im going to step away from this. i’ll try again tomorrow

thanks for your help

np

im an idiot, i had tls on.

something like this :

module "ec2" {
  source  = "cloudposse/ec2-instance/aws"
  version = "0.32.1"

  enabled          = module.this.enabled
  ami              = data.aws_ami.default.id
  ami_owner        = "amazon"
  ssh_key_pair     = null
  vpc_id           = local.vpc_id
  subnet           = local.private_subnet_ids[0]
  instance_type    = var.instance_type
  security_groups  = [module.default_sg.id]
  user_data_base64 = base64encode(data.template_file.userdata[0].rendered)
  root_volume_size = 40
  root_volume_type = "standard"

  associate_public_ip_address   = false
  root_block_device_encrypted   = true
  create_default_security_group = false

  context = module.this.context
}

hi @jose.amengual the problem i’m having is between aws region where one region is set to use user_data_base64 and another region is set to use user_data . Trying to find some way of using a single aws_instance resource just to accomplish the use of either or. Just an example

hope that makes sense

just an example above not really the code

why not to use base64 everywhere?

Well.. that is the plan but at this moment I’m migrating state and user data argument are diff for each aws region unfortunately

The right way is to keep them consistent for each region and idk why this person did it this way

you could have a local that check against a list of non-base64 regions and use that to decide

the list will get smaller once you migrate

until is empty

and you can start a comment like

#### I HATE THIS, PLEASE MIGRATE

and then define the local

hmm trying to picture what you mean by using local sorry

a local variable

base64_regions = { us-west-2: true, us-east-2: false}

sorry i meant to say how would you use a local variable to switch between which resource argument to use (user_data vs user_data_base64) within your aws_instance resource block?

since both will conflict with each other

base64_region_enabled = var.region == base64_regions[${var.region}] ? true : false

something like that

and then you set the value to null

I think if you se it to null you can define it but it will not be used

so it will not conflic

yes this would work in the resource but how would you tell in your resource to use just user_data since that would also need to be included in the aws_instance block?

Wouldn’t having this cause conflict error

resource "aws_instance" "this" {
user_data_base64 =  local.base64_region_enabled ? base64encode(
  templatefile("${path.root}/cloud-config/test.yml" : null
user_data = ""
} 

something like that

you null that too

ah ok let me give that a try thx Pepe!

np

It might not work, but give it a try

yeah doesn’t work since it complains about conflicts between the two resource arguments. I’ve tried this already this.

even with null?

yes

then use our module

and do a count to enable disable the base64

you can instantiate two, one that will do base64 one that not

do you have a direct link to the module i can review?

no need i can find it from ec2-instance/aws

thx

i will give the module a try tomorrow thx again!

np

You can see in the actions table, that no condition keys are supported for the cloudwatch:ListMetrics action.

It’s just that i want to see the cloudwatch metrics for the particular cluster

and that can be done by tagging the resources

for a particular cluster

Not with IAM permissions. IAM permissions are solely to allow or deny a request.

Is there any other way to do so!

yes, terraform often reorders array values

see https://github.com/hashicorp/terraform-provider-aws/issues/11801

also if anyone wants to review, please feel free.

i was thinking about adding a test here but im a bit of a noob

we have many EKS modules, so best to present which one in particular

the likely explanation is the module was refactored to “create before destroy” to make blue/green cluster upgrades easier.

terraform-aws-modules are not “normal”. there are no “normal” modules actually. cloudposse and terraform-aws-modules are same in terms of origin and support, made by community and supported by community

why CP’s is not normal?

cloudposse/terraform-aws-eks-cluster is maintained by Cloud Posse

terraform-aws-modules modules are maintained by @antonbabenko and other people

I saw a lot of misunderstanding about terraform-aws-modules, due to its naming a lot of people think it’s some kind of “official” modules provided or endorsed by hashicorp

both modules should do almost the same things

I saw a lot of misunderstanding about terraform-aws-modules, due to its naming a lot people think it’s some kind of “official” modules provided or endored by hashicorp

yes, they chose a good name

if i had to choose, i would choose the most “Famous” one, because that might mean that there is biger community and bigger possibilities of “googling for errors”

Let me rephrase it What benefits user will have if choose to use CP’s EKS module?

Cloud Posse has more than 130 modules covering almost all AWS resources (we are adding new modules often)

all modules have similar interfaces, inputs, etc.

and all covered by tests that deploy the modules on a real AWS account

and all modules have a working example (examples/complete ) folder that gets deployed and tested by Terratest (look into test folder)

not forget to mention, all the modules are used in production at tens of Cloud Posse’s customers ( so we maintain them and fix bugs/issues as they discovered)

I’m pretty sure the same could be said for terraform-aws-modules, but CP does not maintain those

my personal gripe with cloudposse modules, is that they versioned as 0.x, which means (according to semver) that they can break backward compatibility on minor version changes. as end user I have to actively monitor releases and verify code changes. terraform-aws-modules are more conservative in introducing breaking changes

we try to not break the modules, but since we have many of them and we constantly improve them, and terraform and AWS make changes/improvements all the time, some breaking changes could and will be introduced

we create releases from each change, so if you pin to a release (not to main/master), then it would continue working

so the releases perform the same function as the versioning, and having 0.x.x and not 1.0.0 is just for historical reasons, we do not consider all versions of 0.x.x as minor releases which we will deliberately break (as mentioned, we can/will break the backwards compatibility in some cases when AWS/Terraform introduce changes or when we need to bring a module to our standard and best practices)

@z0rc3r I remember you had some issues with some of the modules, just don’t remember with which ones

please reming me which modules you had issues with, maybe we were in the middle of some refactoring at the time (sorry for any problems you had)

@Andriy Knysh (Cloud Posse) this thread is great. I appreciate your candor, helpfulness and all the work your team does!

@Andriy Knysh (Cloud Posse) this one was painful https://github.com/cloudposse/terraform-aws-eks-cluster/pull/114 because I had to migrate states for this release and following. I do pin versions, but also perform periodic dependency refresh, like with any other code

my point is with 0.x I cannot expect any stability and every version update requires rigorous review. with terraform-aws-modules if I see update from 4.3 to 4.6 for example, I know my code will continue working as expected

Fair point, we’ll discuss versioning and improve it, thanks

@z0rc3r yes, the module was kind of broken b/c of the security group update, and sorry, we did not catch it. Should not happen again at least for the minor versions

as much as I hate we had to break compatibility, this is another reason why we’re still on 0.x - we need to continue standardization of our modules before the interface can stabilize. this overhaul of security group management (on the heels of our context,tf updates) is one of the last major things we need to undertake.

i suspect we might also need to do one more pass at IAM roles/policies and then our modules will be ultimately flexible and standardized for interoperability.

@Andriy Knysh (Cloud Posse) any chance you know or who can answer? thanks.

@ekristen sorry for the confusion, please use 0.25.0

we started to update the modules to a new security group module, which was not completed 100%

this is already fixed, and we’ll release new versions of the other modules soon

Copy. Should you all delete 0.26.x or mark them as pre-release or release 0.27.0 that’s an update of 0.25.0 to prevent people from using it? For example I’m using renovate to keep all my modules up-to-date and now I have a lot of terraform modules asking to update to a broken version

as for VPC, there is not much difference b/w 0.25.0 and what we wanted to improve - it does create a VPC and other resources w/o any issues

I see they all marked as pre-release https://github.com/cloudposse/terraform-aws-vpc/releases

oh that’s new

huh, ok, odd

BTW, since it’s going to be breaking changes, is the plan to rev to 1.0.0?

yes we need to grow up and start using 1.x.x - we’ll discuss that

Sorry @ekristen this is partly my fault. After the 0.26.0 release went out and we realized it was broken and we did not want people building on it, I marked it pre-release after the fact. I thought that would be sufficient, but in fact it was not, for 3 reasons. First, apparently the Renovate bot does not look at the GitHub pre-release designation. Also, by the time I made it pre-release, the Terraform registry had already published it. The third problem is that our auto-release workflow also does not respect the GitHub pre-release designation, and just cuts a normal release even if it is based on a pre-release.

This all led to our normal auto-release and auto-update systems generating several releases of broken code marked as patch releases. This is all stuff we had not dealt with before and why we are still on zero-based releases, but it is stuff @Erik Osterman (Cloud Posse) wants us to get a handle on so we can move to 1.0 releases with confidence.

Hey @Jeremy G (Cloud Posse) thanks for following up. Interestingly the renovate bot does take pre-release into an account, but might not do so retro-actively. I did some troubleshooting with them and now that they are marked as pre-released renovate seems to be ignore it.

Appreciate the information and the work you all have done to standardize this stuff! All my private modules now follow a very similar pattern including using the context module a lot, makes everything much easier.

@ekristen (cc: @Erik Osterman (Cloud Posse)) Thanks for the info on Renovate bot respecting pre-release. Makes sense that it might not revert from release to pre-release the way I did it, but great to know going forward. I think probably the first thing we need to do is fix our auto-release workflow so that if the most recent release was a pre-release, it does not publish a non-prerelease version.

In any case, thank you for your patience as we work out these kinks.

No problem at all! Thanks for all you do.

so rennovatebot should refer to the source of the modules, and if the source is the registry (vs github), then I don’t even think prerelease meta is available; that’s a github thing. hence, my guess is it’s not respected using the registry as a source. we recently enabled rennovatebot at a customer site well after this whole snaffu (just a few days ago), and it opened PRs for the prereleases. cc: @Dylan

https://www.terraform.io/docs/registry/modules/publish.html#releasing-new-versions

Since [registry.terraform.io](http://registry.terraform.io) supports semantic versioning, I guess we should be able to mark new versions of our Terraform modules as pre-releases by appending some sort of tag (-rc1, etc.) to the version number in the Github release. (Although, idk if we’ve ever had a proof of concept for this.)

In the current situation, where we want to mark something as a pre-release after the fact, we’re looking at something a lot more complicated. Looking at https://registry.terraform.io/modules/cloudposse/vpc/aws/latest there’s definitely no hint that this is a pre-release for renovatebot to pick up on, unless it were able to follow the “source code” link and parse the github release history + tags.

renovate definitely knows how to look at different sources, ie github-releases vs github vs terraform registry. it’s possible when referring to modules via SSH it’s not using github releases and instead using raw git tags, in that case, using -rcN is valid for pre-release in semantic versioning

either the role you are using to provision needs to have access to the root/master account (at least to the state S3 bucket and DynamoDB table), or you need to add a role to the backend config which has permissions to access the S3 bucket and DynamoDB

this is an example of the backend config file backend.tf.json we usually use for that

where the role arn:aws:iam::xxxxxxxxx:role/eg-gbl-root-terraform has the required permissions

oh cool!

note that for cross-account access, you need to have permissions on both sides

let’s say you are using this role to provision TF components eg-uw2-identity-admin

the role is provisioned in the identity account and has admin permissions

the role eg-gbl-root-terraform is provisioned in the root account and has permissions to access the s3 state bucket and dynamoDB table

then, you need to give the role eg-uw2-identity-admin the permissions to assume the eg-gbl-root-terraform role in the other (root) account

and you need to add a trust policy to the role eg-gbl-root-terraform with permissions for eg-uw2-identity-admin to assume the eg-gbl-root-terraform role

so, iam-primary-roles is currently in the identity stack and it doesn’t look like it creates any roles in the root/master account, did i do something wrong? also, do i need to create those roles and policies on my own as a separate component, do i need to modify iam-primary-roles, or can it be done in the yaml

in iam-primary-roles you create the primary roles in the identity account

eg-gbl-root-terraform should be created in the root account using the iam-delegated-roles component

great, that’s what I did. is that supposed to generate roles in the root/master account as well?

the name for the master account is not root, in case that matters, i supplied that name in the root_account_stage_name variable

this is an example of YAML config for the root delegated roles

    iam-delegated-roles:
      vars:
        account_number: "xxxxxx"
        exclude_roles: ["poweruser", "helm"]
        account_role_policy_arns:
          # IAM Policy ARNs to attach to each role, overriding the defaults
          ops: ["arn:aws:iam::aws:policy/ReadOnlyAccess"]
          observer: ["arn:aws:iam::aws:policy/job-function/ViewOnlyAccess"]
          terraform: ["root-terraform"]

        

the name for the master account is not root, in case that matters, i supplied that name in the root_account_stage_name variable

the name could be anything

ok cool

it’s just the function that the account performs, and that’s root (as the root of the Org structure),management (as AWS calls it), or billing

i see

what does root-terraform refer to?

the module will auto-generate the ARN of the role

and the name

so it will be eg-gbl-root-terraform

where eg is the namespace

gbl is the environment (since IAM is global, not region based, we call it gbl and not uw2)

this is where i’m having an issue

root is the stage (account name)

it only creates the roles in identity

terraform is the name of the role

it follows Cloud Posse naming convention of {namespace}-{environment}-{stage}-{name}

oh i see, i just realized i need to use iam-delegated-roles in each stack

Could you tell me what I need to set? I have tried setting dynamodb_table_name parameter but get an error saying that the table already exists.

tables are free, so I wouldn’t worry much about this. If you need one table per stack it’s nbd

what exactly are you setting this on?
I have tried setting dynamodb_table_name parameter

oh. OH

you’re using this https://github.com/cloudposse/terraform-aws-tfstate-backend

I’m not clear on the particular use-case of this module, but if you’re going to repeatedly use it you’ll need to define unique names for buckets and tables, so yes you’ll get 1 of each per thing you’re initializaing

ok, thanks

you should only need to create that once

then you can point each of your terraform root modules to use the dynamodb table and s3 bucket via the backend block

even if it was modified so you could re-use, i would advise against it. architecturally, you want to build decoupled components. 2 different state backends should not share resources.