»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 to awskms. 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:

seal "awskms" {
  region     = "us-east-1"
  secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey"
  endpoint   = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com"

»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 the AWS_REGION or AWS_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 the AWS_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 variable AWS_SESSION_TOKEN.

  • secret_key (string: <required>): The AWS secret access key to use. May also be specified by the AWS_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 the VAULT_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 the AWS_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-related values must be provided, either as environment variables or as configuration parameters.

AWS authentication values:

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

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.


Refer to the Auto-unseal using AWS KMS guide for a step-by-step tutorial.