Documentation on handling of sensitive input variables in aft-global-customizations and aft-account-customizations repositories

[rybons]

Describe the outcome you'd like

Documentation or recommended approaches for handling of sensitive input variables in aft-global-customizations and aft-account-customizations.

Is your feature request related to a problem you are currently experiencing? If so, please describe.

I often have ideas to make use of third-party providers (Harness, for example) in my aft-global-customizations repository. Idea being that it would be useful to automatically integrate the AWS accounts that I provision with third-party tools at the time the account is provisioned.

# Authenticate with Harness

provider "harness" {
  endpoint   = "some_endpoint"
  account_id = "some_account_id"
  platform_api_key = "<sensitive_value>"           <--- How can I manage this value securely within the AFT framework?
}

# Provision Harness resources

resource "harness_platform_connector_aws" "aws" {
  ...
}

Additional context

If I were to run the sample Terraform code above, but outside of the AFT framework (as a normal Terraform project), I would have some safer options for securing the input variable for platform_api_key. First, I would set a variable:

provider "harness" {
  endpoint   = "..."
  account_id = "..."
  platform_api_key = var.secret_api_key
}

Then, I have several options for safely providing values to the secret_api_key variable:

• Configure the value for the variable using .tfvars files (not committed to version control).
• Configure the value for the variable using environment variables (i.e. TF_VAR_secret_api_key).
• Configure the value for the variable in my Terraform Cloud workspace and mark it as sensitive.
• Configure a data source to retrieve the value from some other secrets manager.

However, I'm unaware as to how I'd make use of any of the methods above within the AFT workflow because:

• AFT seems to have strict control over the creation and management of the workspace (working directory), meaning I don't think I can make use of environment variables or tfvars files the same way I would in my local environment.
• I typically I do not make use of input variables at all when writing Terraform code in aft-global-customizations because I really only need variables if I want something to be dynamic (be different for each provisioned member account). If I needed to do this, I would make use of custom_fields in the account request, rather than variables. Managing secrets as a custom_field in the account request also seems difficult.
• Retrieving the secret from a third-party secrets managers will typically also require a key to the secrets manager itself, creating a similar issue.

[v-rosa]

I tipically use AWS Secrets Manager for such use case.

Provision the SM instance, provide cross account access and refer it in the aft-providers.jinja e.g.:

data "aws_secretsmanager_secret" "harness" {
  arn = "arn:aws:secretsmanager:us-east-1:123456789secret:harness-q1w23e"
}

provider "harness" {
  endpoint   = "..."
  account_id = "..."
  platform_api_key = jsondecode(data.aws_secretsmanager_secret_version.harness.secret_string)["platform_api_key "]
}

[rybons]

I tipically use AWS Secrets Manager for such use case.

Provision the SM instance, provide cross account access and refer it in the aft-providers.jinja e.g.:

data "aws_secretsmanager_secret" "harness" {
  arn = "arn:aws:secretsmanager:us-east-1:123456789secret:harness-q1w23e"
}

provider "harness" {
  endpoint   = "..."
  account_id = "..."
  platform_api_key = jsondecode(data.aws_secretsmanager_secret_version.harness.secret_string)["platform_api_key "]
}

@v-rosa Thanks, I considered this as well. To clarify:

Is the secret in your example (arn:aws:secretsmanager:us-east-1:123456789secret:harness-q1w23e) managed in a "central" AWS account, made accessible to other accounts in your AWS organization? (i.e. like this)

I suspect this would need to be the case, as if you were creating this secret for each account, you'd have similar problems populating the value of the secret at the time the account is created.

I suppose the AFT-management account might be the most logical place to store these secrets.

[v-rosa]

(....) managed in a "central" AWS account, made accessible to other accounts in your AWS organization?

Exactly.

as if you were creating this secret for each account, you'd have similar problems populating the value of the secret at the time the account is created. I suppose the AFT-management account might be the most logical place to store these secrets.

AFT-mgt account could be used for sure, assuming it is a very restricted account. In that case, you could import the AFT-mgt account into the the AFT pipelines and create secrets for the vended accounts from there. You can then restrict the access to the secrets/cmk to the vended account AFT role.