Customization of key use

[mikn]

Some of the key/cert pairs we want to issue, we want to make sure are only used for client certificate authentication, so it would be cool if there was a way to customise the key usages requested on the CSR.

[johngmyers]

Seems reasonable on the face of it.

Since Kubernetes currently doesn't permit particular containers to have a different service account than other containers in the POD, the approval side would have to be configured to only permit the server usage to a subset of service accounts. Otherwise some code injected into a main container could just issue its own request for a server cert.

[johngmyers]

I should mention that I'm primarily interested in the server cert use case and had it also request client certificate use because there seemed to be little reason not to. Proofpoint uses OAuth for client authentication to its own services, though we do support X.509 client certificates for SMTP relay.

The Kubernetes container identity working group appears to be primarily working on the client authentication use case and they seem to have a fairly strong preference for JWT over X.509.

Server authentication pretty much has to be X.509. I would caution going too far down the rathole of X.509 client authentication, especially since Kubernetes seems to be going in a different direction.

I am willing to take PRs supporting client authentication use cases as long as they don't make the code too convoluted.

[mikn]

Oh, I would also love to use JWT or other client authentication mechanisms, but some third-party software that we are implementing does currently not support other safe authentication mechanisms than client cert, hence me needing these features. :)

[johngmyers]

Good to know. You'll probably need a way for kapprover to filter on the inverse of keyusage so you can have separate approval flows for server cert and not server cert.