Role option to set alias name to Service Account's "namespace/name" instead of uid #103
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Adds a Role Configuration Option to allow using the
serviceAccount.namespace()/serviceAccount.name()
to be the alias name instead of theserviceAccount.uid()
.This option allows tying Entities to Kubernetes service accounts, before they exists, and even after they been deleted and recreated. In a practical sense it allows deploying testing/staging namespaces and allowing vault to manage the credentials without needing to update vault with new service account uids every time a deployment occurs.
The UI user's experience is also improved as the Entities>Alias list is now human readable. The user now knows what service account the alias is for without having to click and inspect the metadata of every single alias. Furthermore as namespaces get deleted and recreated the list of Entities and Aliases does not continue to grow.
Design of Change
The
path_role.go
implementation was updated to include this new option in the UI as well as visible in thevault read|write auth/kubernetes/role/$ROLE
commands. Andpath_login.go
was updated to check if the new option is true and if so use the namespace and service account name separated by a/
instead of the uid.The
/
was chosen over the existing-
used in theDisplayName
as the former is an invalid character in a Kubernetes namespace. A.
could work as well.The name of the option
HumanReadableAlias
is surely not the best, any feedback on a better name is welcome. I've noticed in other parts of this plugindisable_
seems to be the preferred flag/boolean prefix. PerhapsDisableUidAlias
?Finally enabling this option can open up security concerns, as a service account being deleted and recreated will correspond to the same alias and entity. Perhaps a warning should be added outlining this fact? Any suggestion on how to add such a warning would be appreciated.
Related Issues/Pull Requests
#39 Using
-
as the separator forDisplayName
Contributor Checklist
[ x ] Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet
This is a plugin specific option. As such it isn't clear more documentation is needed.
[ ] Add output for any tests not ran in CI to the PR description (eg, acceptance tests)
Change has been tested by using
vault write sys/plugins/catalog/auth/kubernetes sha256=$SHA256SUM command=vault-plugin-auth-kubernetes
to overwrite the builtin version on vault 1.6.2. Please indicate what information is required to show that it has been tested.[ x ] Backwards compatible
This change defaults to the current behavior and as such doesn't affect any existing infrastructure.