»awskms
Seal
The AWS KMS seal configures Vault to use AWS KMS as the seal wrapping mechanism. The AWS KMS seal is activated by one of the following:
- The presence of a
seal "awskms"
block in Vault's configuration file - The presence of the environment variable
VAULT_SEAL_TYPE
set toawskms
. If enabling via environment variable, all other required values specific to AWS KMS (i.e.VAULT_AWSKMS_SEAL_KEY_ID
) must be also supplied, as well as all other AWS-related environment variables that lends to successful authentication (i.e.AWS_ACCESS_KEY_ID
, etc.).
»awskms
Example
This example shows configuring AWS KMS seal through the Vault configuration file by providing all the required values:
»awskms
Parameters
These parameters apply to the seal
stanza in the Vault configuration file:
region
(string: "us-east-1")
: The AWS region where the encryption key lives. If not provided, may be populated from theAWS_REGION
orAWS_DEFAULT_REGION
environment variables, from your~/.aws/config
file, or from instance metadata.access_key
(string: <required>)
: The AWS access key ID to use. May also be specified by theAWS_ACCESS_KEY_ID
environment variable or as part of the AWS profile from the AWS CLI or instance profile.session_token
(string: "")
: Specifies the AWS session token. This can also be provided via the environment variableAWS_SESSION_TOKEN
.secret_key
(string: <required>)
: The AWS secret access key to use. May also be specified by theAWS_SECRET_ACCESS_KEY
environment variable or as part of the AWS profile from the AWS CLI or instance profile.kms_key_id
(string: <required>)
: The AWS KMS key ID to use for encryption and decryption. May also be specified by theVAULT_AWSKMS_SEAL_KEY_ID
environment variable.endpoint
(string: "")
: The KMS API endpoint to be used to make AWS KMS requests. May also be specified by theAWS_KMS_ENDPOINT
environment variable. This is useful, for example, when connecting to KMS over a VPC Endpoint. If not set, Vault will use the default API endpoint for your region.
»Authentication
Authentication-related values must be provided, either as environment variables or as configuration parameters.
Note: Although the configuration file allows you to pass in
AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
as part of the seal's parameters, it
is strongly recommended to set these values via environment variables.
AWS authentication values:
AWS_REGION
orAWS_DEFAULT_REGION
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
Note: The client uses the official AWS SDK and will use the specified credentials, environment credentials, shared file credentials, or IAM role/ECS task credentials in that order, if the above AWS specific values are not provided.
Vault needs the following permissions on the KMS key:
These can be granted via IAM permissions on the principal that Vault uses, on the KMS key policy for the KMS key, or via KMS Grants on the key.
»awskms
Environment Variables
Alternatively, the AWS KMS seal can be activated by providing the following environment variables.
Vault Seal specific values:
»Key Rotation
This seal supports rotating the master keys defined in AWS KMS doc. Both automatic rotation and manual rotation is supported for KMS since the key information is stored with the encrypted data. Old keys must not be disabled or deleted and are used to decrypt older data. Any new or updated data will be encrypted with the current key defined in the seal configuration or set to current under a key alias.
»AWS Instance Metadata Timeout
Affects Vault 1.4 and later
Anytime Vault uses the instance metadata service on an EC2 instance, such as for getting credentials from the instance profile, there may be a delay with the introduction of v2 of the instance metadata service (IMDSv2). The AWS SDK used by Vault first attempts to connect to IMDSv2, and if that times out, it falls back to v1. In Vault 1.4, this timeout can take up to 2 minutes. In Vault 1.5.5 and later, it can take up to 2 seconds with this fix: #10133.
The timeout occurs in situations where there is a proxy between Vault and IMDSv2, and the instance hop limit is set to less than the number of "hops" between Vault and IMDSv2. For example, if Vault is running in docker on an EC2 instance with the instance hop limit set to 1, the AWS SDK client will attempt to connect to IMDSv2, timeout, and fall back to IMDSv1 because of the extra network hop between docker and IMDS.
To avoid the timeout behavior, the hop limit may be adjusted on the underlying EC2 instances. With the docker example, setting the hop limit to 2 will allow the AWS SDK in Vault to connect to IMDSv2 without delay.
»Learn
Refer to the Auto-unseal using AWS KMS guide for a step-by-step tutorial.