Adding 'static_metadata' configuraiton parameter to roles

[dwimsey]

Overview

This change adds a 'static_metadata' parameter to roles used in this plugin. This parameter includes key/value pairs that are applied to the entity alias created when logging in using the JWT method.

Where the existing 'claim_mappings' parameter for roles allows data from the JWT claims to be mapped into metadata, this allow static values to be used in the same way.

In our instance, we are authenticating multiple kubernetes clusters to vault using JWT. The claim_mappings are used to map kubernetes namespace and service account name into metadata, but the JWT itself does not contain any information to identify which kubernetes cluster. Kubernetes does not allow for any sort of modifications to this JWT other than Audience.

This feature will allow us to include a cluster_name metadata value in vault configuration to make up for the missing data in the JWT. Multiple JWT auth plugin endpoints are used to provide distinction between each kubernetes cluster, with the roles created under that instance having the correct metadata values assigned to the cluster_name metadata key.

Ultimately these metadata values would be used in policy templates to allow service accounts automatic access to certain features according to metadata values matching path or attributes.

Design of Change

This change introduces a new configuration parameter to 'roles'. The parameter contains a key/value map of target metadata field names and the value to be inserted. This was done by modifying the role create/update function to validate the input map and ensure it does not collide with metadata reserved words or existing metadata keys. The metadata itself is injected into the metadata map at login immediately after the values for 'claim_mappings' have been injected into the metadata field. This allows the static values to work in conjunction with 'claim_mappings' to provide a 'default' should the value not be provided in the JWT for 'claim_mappings' to pickup.

This is not the most technically correct solution to our problem, but it does provide a flexible work around that provides additional value outside of our use case. This was very easy to implement inline of existing code.

For our use case, doing this at the auth endpoint level for all roles under that endpoint would be more appropriate, but provides less flexibility.

The most appropriate for our use case would be to be able to at metadata based on they key used to validate the token, so we could use one endpoint for all kubernetes clusters, and then based on which public key was used to validate the JWT assign metadata values specified for that key in the same way as per role here. This is less flexable than at the role level, but keeps the metadata more closely associated with what it represents - different kubernetes clusters and related metadata.

Related Issues/Pull Requests

Issue #344

Contributor Checklist

[ ] Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet
TO DO
My Docs PR Link
Example
[ ] Add output for any tests not ran in CI to the PR description (eg, acceptance tests)
[ ] Backwards compatible
This change is backwards compatible. Behavior is identical to prior behavior unless the 'static_metadata' parameter is configured.

[dwimsey]

This is what I felt was the quickest to implement implementation, but I am happy to modify or correct however is appropriate. Ultimately I just need a way to assign different metadata based on which kubernetes cluster a JWT token is from.

[dwimsey]

If the overall implementation is acceptable I will be happy to add tests and documentation.