Wildcard support on roles

[idcmp]

As discussed here: https://groups.google.com/forum/#!topic/vault-tool/WcujbsujdgE it would be ideal to support wildcards for service_account_names when defining roles for this backend. This allows an administrator to provide a templated policy for Kubernetes services in Vault and moves "account management" from Vault to the Kubernetes API (kubectl create serviceaccount ..).

In effect, an administrator should be able to run:

vault write auth/kubernetes/role/kubernetes-service \
    bound_service_account_names=* \
    bound_service_account_namespaces=default \
    policies=templated-kubernetes-service \
    ttl=1h

Then any ServiceAccount in the default namespace would match this role and be entitled to the resolved templated-kubernetes-service policy.

Further, it should be possibly to do simple postfix wildcards (like policies do in path matching), such that:

  bound_service_account_names=sa-*

Would match any service account starting with sa-.

[mterron]

Hi Team,

Why can't we create a role with bound_service_account_names=* and bound_service_account_namespaces=* at the same time?

I saw the documentation where it states that it is not possible but no rationale is provided for that decision.

Thanks

[idcmp]

Also relevant to the discussion: https://github.com/kubernetes/community/pull/1460/files

[james-atwill-hs]

PR 58 mostly solves this issue with PR 66 fixing the double-wildcard check. When PR66 is merged this issue can be fully closed.

[idcmp]

Looking at PR58, its usage of StrContainsGlob makes it such that one cannot have a serviceaccount of 'foo' and a wildcard entry of 'f*' since the iterating order is undefined.

[tyrannosaurus-becks]

Hi @idcmp , thanks for opening this issue.

Question. I'm trying to understand what further needs to be done to consider this work complete. I added a PR allowing service account names and namespaces to be splat, mentioned above. The other piece is, I'm looking at your comment and I'm not sure I understand it.

Looking at PR58, its usage of StrContainsGlob makes it such that one cannot have a serviceaccount of 'foo' and a wildcard entry of 'f*' since the iterating order is undefined.

When I go look at the code, it seems that both are allowable. I added a test here and it passes.

Can you clarify on that? Or, really my question is, will this issue be fully resolved when the above PR is merged, or if not, what additional changes are needed?

Thanks!

[tyrannosaurus-becks]

Hi! Closing this because it appears done but please feel free to reopen it if further is needed. Thanks!

[james-atwill-hs]

Hey, I'll be able to cycle back on this in a couple weeks and will reopen if needed. Thanks for taking care of this issue (and the other one)!

[james-atwill-hs]

We made a "generic" role that all services ask to authenticate as. It's a bit counter-intuitive, but it's working now and services that can use our templated policies are being cut over. Thanks!