You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in issue #65, a scoped token also includes the name of the pod it has been injected into.
What do you think about about adding an additional configuration parameter that would allow a vault auth role specification to allow matching not only on the kubernetes namespace and service account names, but also on the pod name (possibly using wildcards)?
This would allow to assign roles also based on the pod identity in all those cases when it is not possible to assign different service accounts to different pods, like when building (as in the referenced issue) with the gitlab runner that does assign the same service account to all the spawned build jobs.
If you think this is a reasonable feature to add, I can work to contribute a pull request.
The text was updated successfully, but these errors were encountered:
Please add this feature. Currently, we'd have to create separate service accounts for each pod/deployment. With the additional pod level matching, we'd only need a single service account, greatly reducing the complexity of the setup.
I am very interested in this feature, I could help if the feature is wanted and someone guides me in the right direction.
Currently any pod within the same service account is able to read the secrets from all the others.
This feature will provide a more granular access control to vault secrets at the pod level.
In case of grouped pods (deployments, daemon-sets, statefull-sets) pods should have access to the same secrets, therefore this feature should also allow setting a prefix to match the pod group.
As described in issue #65, a scoped token also includes the name of the pod it has been injected into.
What do you think about about adding an additional configuration parameter that would allow a vault auth role specification to allow matching not only on the kubernetes namespace and service account names, but also on the pod name (possibly using wildcards)?
This would allow to assign roles also based on the pod identity in all those cases when it is not possible to assign different service accounts to different pods, like when building (as in the referenced issue) with the gitlab runner that does assign the same service account to all the spawned build jobs.
If you think this is a reasonable feature to add, I can work to contribute a pull request.
The text was updated successfully, but these errors were encountered: