Overview
This page contains the list of deprecations and important or breaking changes for Vault 1.3.3 compared to 1.3.4. Please read it carefully.
The AWS auth engine
Users of the AWS Auth Engine should be cautious with this upgrade, because in 1.3.2 we began adding metadata to tokens issued with this method. While the metadata does help with tying tokens to a particular person or machine, it also can also take a performance toll.
Whether there's a performance toll depends on if and how you've configured the
auth/aws/config/identity
endpoint. To determine if you could be effected:
- Read your identity configuration:
$ vault read auth/aws/config/identity
- Determine what Vault is using for identity (
role_id
if unconfigured) - Determine what role type(s) you're using (
iam
and/orec2
) - Consider the rate of change of the metadata fields for each role type
Metadata fields for iam
roles:
client_arn
canonical_arn
client_user_id
auth_type
inferred_entity_type
inferred_entity_id
inferred_aws_region
account_id
Metadata fields for ec2
roles:
For example, if you use role_id
for identity and only iam
roles, and
many machines use the same role, you would conclude that the client_arn
for the machines logging in would have a high rate of change, and so you'd
see a new storage write each time a new machine logged in under that role.
If you use role_id
for identity and only iam
roles, and
and only one long-lived machine used the role, you would conclude that the
client_arn
for the machines logging in would have a low rate of change.
Unless you added the optional "role-session" to its ARN, in which case you
could still have a higher rate of change.
However, if you had configured identity to use an iam_alias
of the full_arn
,
or an ec2_alias
of instance_id
, you would be likely to see a lower rate of
change for all fields.
For users seeing a performance issue, we recommend implementing one of the aliases above, or waiting until a patch is released providing greater flexibility around whether to use this functionality.