» vault_aws_access_credentials

Reads AWS credentials from an AWS secret backend in Vault.

» Example Usage

resource "vault_aws_secret_backend" "aws" {
  access_key = "AKIA....."
  secret_key = "SECRETKEYFROMAWS"
}

resource "vault_aws_secret_backend_role" "role" {
  backend = "${vault_aws_secret_backend.aws.path}"
  name    = "test"

  policy = <<EOT
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}
EOT
}

# generally, these blocks would be in a different module
data "vault_aws_access_credentials" "creds" {
  backend = "${vault_aws_secret_backend.aws.path}"
  role    = "${vault_aws_secret_backend_role.role.name}"
}

provider "aws" {
  access_key = "${data.vault_aws_access_credentials.creds.access_key}"
  secret_key = "${data.vault_aws_access_credentials.creds.secret_key}"
}

» Argument Reference

The following arguments are supported:

  • backend - (Required) The path to the AWS secret backend to read credentials from, with no leading or trailing /s.

  • role - (Required) The name of the AWS secret backend role to read credentials from, with no leading or trailing /s.

  • type - (Optional) The type of credentials to read. Defaults to "creds", which just returns an AWS Access Key ID and Secret Key. Can also be set to "sts", which will return a security token in addition to the keys.

  • role_arn - (Required if role has multiple ARNs) The specific AWS ARN to use from the configured role. If the role does not have multiple ARNs, this does not need to be specified.

» Attributes Reference

In addition to the arguments above, the following attributes are exported:

  • access_key - The AWS Access Key ID returned by Vault.

  • secret_key - The AWS Secret Key returned by Vault.

  • security_token - The STS token returned by Vault, if any.

  • lease_id - The lease identifier assigned by Vault.

  • lease_duration - The duration of the secret lease, in seconds relative to the time the data was requested. Once this time has passed any plan generated with this data may fail to apply.

  • lease_start_time - As a convenience, this records the current time on the computer where Terraform is running when the data is requested. This can be used to approximate the absolute time represented by lease_duration, though users must allow for any clock drift and response latency relative to the Vault server.

  • lease_renewable - true if the lease can be renewed using Vault's sys/renew/{lease-id} endpoint. Terraform does not currently support lease renewal, and so it will request a new lease each time this data source is refreshed.