luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

Add info about aws timeouts to docs (#10209) 

In auth/aws, seal/awskms, and secrets/aws, storage/s3, and
storage/dynamodb.

One blurb for the docs pages and one for the .0 upgrade pages.
This commit is contained in:
Theron Voran 2020-10-26 11:15:59 -07:00 committed by GitHub
parent a095d1e809
commit b705d71ae7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 57 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
website/pages/docs/auth/aws.mdx
View File

@ -573,6 +573,10 @@ Policy](#recommended-vault-iam-policy) except it doesn't need any further
Furthermore, in the master account, Vault must be granted the action `sts:AssumeRole`
for the IAM Role to be assumed.
### AWS Instance Metadata Timeout
@include 'partials/aws-imds-timeout.mdx'
## Authentication
### Via the CLI

4
website/pages/docs/configuration/seal/awskms.mdx
View File

@ -112,6 +112,10 @@ encrypted data. Old keys must not be disabled or deleted and are used to decrypt
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
@include 'partials/aws-imds-timeout.mdx'
## Learn
Refer to the [Auto-unseal using AWS KMS](https://learn.hashicorp.com/vault/operations/ops-autounseal-aws-kms)

4
website/pages/docs/configuration/storage/dynamodb.mdx
View File

@ -155,6 +155,10 @@ If the table does not already exist, Vault will try to create it, with read and
write capacities set to the values of `read_capacity` and `write_capacity`
respectively.
## AWS Instance Metadata Timeout
@include 'partials/aws-imds-timeout.mdx'
## DynamoDB Examples of Vault Configuration
### Custom Table and Read-Write Capacity

4
website/pages/docs/configuration/storage/s3.mdx
View File

@ -118,3 +118,7 @@ storage "s3" {
```
[s3]: https://aws.amazon.com/s3/
## AWS Instance Metadata Timeouts
@include 'partials/aws-imds-timeout.mdx'

4
website/pages/docs/secrets/aws/index.mdx
View File

@ -457,6 +457,10 @@ See http://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.ht
Vault 0.5.1 or later is recommended when using STS tokens to avoid validation
errors for exceeding the AWS limit of 32 characters on STS token names.
### AWS Instance Metadata Timeouts
@include 'partials/aws-imds-timeout.mdx'
## API
The AWS secrets engine has a full HTTP API. Please see the

2
website/pages/docs/upgrading/upgrade-to-1.4.0.mdx
View File

@ -23,3 +23,5 @@ for Vault 1.3.X compared to 1.4.0. Please read it carefully.
@include 'partials/ldap-upndomain-issue.mdx'
@include 'partials/okta-group-pagination.mdx'
@include 'partials/aws-imds-timeout-upgrade.mdx'

2
website/pages/docs/upgrading/upgrade-to-1.5.0.mdx
View File

@ -89,3 +89,5 @@ The workaround is to quote the strings in question, as in:
```
@include 'partials/okta-group-pagination.mdx'
@include 'partials/aws-imds-timeout-upgrade.mdx'

9
website/pages/partials/aws-imds-timeout-upgrade.mdx Normal file
View File

@ -0,0 +1,9 @@
## AWS Instance Metadata Timeout
In 1.4.0 Vault started using an updated AWS Go SDK which had support for v2 of
the [EC2 instance metadata service][aws-ec2-imdsv2]. However, due to the way the
SDK was configured in Vault, there can be a delay of around 2 minutes when Vault
relies on the instance metadata service for credentials. A fix that reduces the
delay went into 1.5.5: [#10133](https://github.com/hashicorp/vault/pull/10133).
[aws-ec2-imdsv2]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

24
website/pages/partials/aws-imds-timeout.mdx Normal file
View File

@ -0,0 +1,24 @@
~> Affects Vault 1.4 and later
Anytime Vault uses the [instance metadata service][aws-ec2-mds] 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)][aws-ec2-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](https://github.com/hashicorp/vault/pull/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][aws-ec2-imdsv2-config]. With the docker example, setting the hop
limit to 2 will allow the AWS SDK in Vault to connect to IMDSv2 without delay.
[aws-ec2-mds]: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
[aws-ec2-imdsv2]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
[aws-ec2-imdsv2-config]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#configuring-instance-metadata-options