Joe, thank you for the writeup! I am wondering if you can share an example of your k8s ClusterRole and ClusterRoleBinding objects? As I am working through deploying this, the configuration I have going right now would allow users to set their common_name to anything and it seems k8s is respecting the cn as much as the organizations within the cert. This would allow users to act as anyone as long as they have permission to sign with the vault role.

Good idea. I'll write something up.

I am continuing to experiment with this. I created a k8s role and rolebinding that gives a generic user no permissions. I also have roles that do have permissions attached to them, and the certificate's organizations are correctly attaching the generic user to the roles on each api query. Vault logs the auth backend user to the pki secret backend, so we can audit who had access to what.

https://github.com/kubernet...

JoeJulian 5+

Spoke with several people here at Helm Summit. This does appear to be a bug and I'll file it tomorrow when I get home.

Quick (hopefully) question. Why issue intermediates for each group? It looks like when you setup the intermediate roles, the roles are specifying the organization which in Kube RBAC translates to "group". This means that role "readonly" for example can get organization system:readonly and it reduces the amount of intermediates you need significantly. It DOES mean that an intermediate can issue certs for any party - but it looks like that can happen anyways if you're not careful?