How to mark as sensitive external modifications?

Terraform
1

Hello,

I’m trying to hide sensitive information from the environment.variables block of an aws_lambda_function resource (but could be applicable to any kind of resources).
My use-case:
Terraform bootstraps a lambda without any environment configuration and with a stub code.
Then, my other deployment tool deploys the real code for the lambda + environment variables.

In order to prevent conflicts, I added this lifecycle to my resource:

  lifecycle {
    ignore_changes = [
      source_code_hash,
      environment,                                                                                                                                                                                                                          
      s3_bucket,
      s3_key,
    ]
  }

But after deploying the application, terraform informs me that there was a change in my lambda:

  # module.dev_zdcl.module.lambda.aws_lambda_function.this has changed
  ~ resource "aws_lambda_function" "this" {
        id                             = "xxx"
      ~ last_modified                  = "2022-01-11T19:15:43.000+0000" -> "2022-01-13T21:10:35.000+0000"
      ~ source_code_hash               = "qay8LyeUBBnbLaVCRhVB87FeTkXK0lbf/w7xSFeuv+s=" -> "KsZZJgGLwIrfD2QBkKnvGBXexDgrtqc54dw9bEC+/vs="
      ~ source_code_size               = 33535908 -> 33824092
        # (16 unchanged attributes hidden)

      ~ environment {
          ~ variables = {
              + "UBER_SECRET"             = "1"
              + "SUPER_SECRET"            = "2"
            }
        }

        # (3 unchanged blocks hidden)
    }

I tried different syntaxes like:

resource "aws_lambda_function" "this" {
  [...]
  environment {
    variables = sensitive({})
  }
}

but I’m unable to hide these vars.

Is there a way to do that with the current version of Terraform ?

Thanks a lot and have a nice day !

2

Actually I wouldn’t consider this a terraform question but rather a general approach. As you are also using names like *SECRECT* I’d recommend to use AWS Secretsmanager instead.
This is also the recommended way within the docs.

3

Hi @pois,

For arguments that belong to providers it’s up to the provider itself to mark attributes as potentially containing sensitive values when needed. There isn’t currently any way to force that just from the calling module, without any modifications to the provider.

As @tbugfinder noted, environment variables aren’t an ideal solution for passing secret values to Lambda functions anyway, because their values can be retrieved in cleartext via the API – exactly as the AWS provider did here to show you these changes. I would suggest adopting a different strategy where the environment variables are only identifiers or locators for secret material stored somewhere else, so that the secrets themselves are kept in a system designed for that purpose.