Data source for STS temporary credentials

[KyleKotowick]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Implement a data source for obtaining STS tokens for the credentials configured on the AWS provider.

There are many things supported by the AWS CLI that aren't supported by the Terraform AWS provider. Unfortunately, this will always be the case as it takes months, or sometimes years, for new AWS features to be supported in the Terraform AWS provider.

To use these features, engineers often resort to using the AWS CLI with the external data source. It's an unfortunate workaround, but it works if done correctly. The problem is, how do you provide appropriate credentials to the AWS CLI commands? The easiest way is to pass it a profile argument, but it becomes complicated if you want to be able to support the same credential sources as the AWS provider (access keys, profiles, environment variables, assumed roles, etc.).

It would be very helpful if there was a data source in the AWS provider that allowed obtaining an STS token with the same permissions (or an optionally restricted subset) as the credentials that the AWS provider is configured with. This would mean utilizing the appropriate STS action API, depending on how the AWS provider is configured.

Note: I remember seeing somewhere in Terraform development guidelines (can't find the link now) that TF will never allow resources or data sources that expose the provider's credentials. I agree with that, so it's important to note that this data source would not expose provider credentials, it would expose temporary credentials that were created via STS (from a security perspective, no different than creating a new aws_iam_user resource with a corresponding aws_iam_access_key resource).

New or Affected Resource(s)

• data aws_sts_credentials

Potential Terraform Configuration

An example of how you would use this to obtain a list of all S3 buckets accessible by the credentials configured for the provider (something not currently supported in the Terraform AWS provider):

provider "aws" {
  region = "us-east-1"
  profile = "my_aws_admin"
  assume_role {
    role_arn     = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
    session_name = "SESSION_NAME"
    external_id  = "EXTERNAL_ID"
  }
}

data "aws_sts_credentials" "list_s3_token" {
  // An optional policy that further restricts the access of the token (final permissions will be the intersection
  // of the provider's permissions, this policy, and any policies listed in policy_arns), similar to STS AssumeRole's "Policy" input
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
        {
            Sid = "VisualEditor0",
            Effect = "Allow",
            Action = "s3:ListAllMyBuckets",
            Resource = "*"
        }
    ]
  })

  // An optional list of existing policy ARNs to use to further restrict permissions, similar to STS AssumeRole's 
  // "PolicyArns" input
  policy_arns = [
    "arn:of:a:policy"
  ]
}

// A module we built that wraps the external data source in a more convenient format
module "list_buckets" {
  source  = "Invicton-Labs/shell-data/external"
  version = "~> 0.2.1"

  // The AWS CLI command to run
  command_unix = "aws s3api list-buckets"

  // Provide the temporary credentials as environment variables
  environment = {
    AWS_ACCESS_KEY_ID = data.aws_sts_token.aws_sts_credentials.credentials.access_key_id
    AWS_SECRET_ACCESS_KEY = data.aws_sts_token.aws_sts_credentials.credentials.secret_access_key
    AWS_SESSION_TOKEN = data.aws_sts_token.aws_sts_credentials.credentials.session_token
  }
}

[github-actions[bot]]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[KyleKotowick]

This issue is not stale, and is still relevant.