-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Kubernetes Secret Engine] allow specifying a namespace selector for the allowed namespace in role. #16222
Comments
I am quite interested in looking at this. What needs to be achieved in terms of logic seems relatively straight-forward. What I am unsure about is how this can be solved in an elegant way on the secret engine configuration. Currently there is only a string array Do you already have an idea on how this should ideally look like? |
Ok so I will start to implement this. I think I will go with the following principles:
If you have any feedback to this, please let me know. I will start the implementation on the plugin with these principles in mind, but it should not be much work to make changes afterwards. |
…espace_selector to external plugin api
…lector if configured in role
The more I work on this, the more I have the feeling it might make sense to allow users to set both I feel like this would give the most flexibility to users, does not break backwards-compatibility, and also makes some parts of the code a little cleaner in terms of behaviour (e.g. what happens on an update? Can a user try to "clear" |
…rameters can be supplied on roles, add integration tests for allowed_kubernetes_namespace_selector
I was on PTO. Thanks for picking this up so quickly. I'd have done very similar choices to your, the only thing I'd change is that I'd make the two Because using a namespaces selector allows to essentially set a super-set of conditions relative to what you can do with |
@raffaelespazzoli sure no worries. Regarding the mutual exclusivity, I agree. The issue I encountered was that when updating the configuration, I was unsure how to handle this. For example, I would prohibit setting both parameters on initial creation of the role. Now suppose someone configures the role to use the standard
Let me know what you think. I will check the feasibility of the two first points next week, and see how elegantly this can be solved. For the performance I would leave it like this for now unless it becomes an issue (which I doubt). I don't want to "pre-optimize" the code, and using a watcher would require an additional Regarding the auth method, yes I can have a look at it next week as well. Not yet sure exactly when, but will definitely have the time at some point. |
@raffaelespazzoli I thought about this a little more. I believe that in theory option 3 would be the most elegant. This would make the two mutually exclusive, and would be elegant in terms of how the update of the role are handled. However, implementing this would change the typing for the API, and would therefore not be backward compatible with typed clients. Therefore I don't think it makes sense to implement it. The two other options I find not very elegant. Regarding your point:
while this is true, I don't see why this points to mutual exclusivity. Do you care to explain this a little more? The way I see it, people can:
Does my reasoning make sense to you? Or do you see this differently? |
…setting both allowed_kubernetes_namespaces and allowed_kubernetes_namespace_selector parameters for role configuration
Regarding the change on the auth engine, I will open an issue that references this on the plugin project, but I will not yet implement it. The auth plugin does not use the standard Kubernetes client, and implementing the namespace label getting will require relatively large changes to the code if we don't want to duplicate too much. I will therefore wait and see what the decision is here, and then implement it once it is clear what way we are going. |
I'm good with the design you are proposing @f4z3r |
… LabelSelector (#16240) * docs(#16222): add documentation for changes in PR hashicorp/vault-plugin-secrets-kubernetes#10 * docs(#16222): add changelog entry * docs(#16222): improve documentation to make the use case of setting both allowed_kubernetes_namespaces and allowed_kubernetes_namespace_selector parameters for role configuration
…espace_selector to external plugin api
…lector if configured in role
…rameters can be supplied on roles, add integration tests for allowed_kubernetes_namespace_selector
Thanks for the discussion here folks, this will be included in Vault 1.12 via hashicorp/vault-plugin-secrets-kubernetes#10 |
Is your feature request related to a problem? Please describe.
When creating a kubernetes secret engine role, one must specify which namespaces should be allowed (https://www.vaultproject.io/api-docs/secret/kubernetes#allowed_kubernetes_namespaces). Namespaces come an go as teams do their work. So, on a very dynamic cluster one would have to constantly update the list of allowed namespaces.
Describe the solution you'd like
Allow to specify a namespace selector instead of an array of namespaces. This will select a dynamic set of namespaces based on their labels. This is the standard approach in Kubernetes to deal with these issues.
Describe alternatives you've considered
As of now, because constantly updating the same configuration is untenable, one would probably end up creating a role for each namespace.
Explain any additional use-cases
Additional context
here is an overview of labels and selector: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
here is what a label selector looks like from a API perspective: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#labelselector-v1-meta
there are go utility functions to quickly check if an object is selected by an label selector.
The text was updated successfully, but these errors were encountered: