SPIFFE identites
mcpherrinm opened this issue · 2 comments
We currently rely on the CN in client cert subjects.
We should support SPIFFE identities.
https://github.com/spiffe/svid/blob/master/SPECIFICATION.md
The first step would be figuring out how to map keywhiz clients to SVID identities.
Those identities look like (examples from SVID spec):
spiffe://staging.acme.com/payments/mysql
or
spiffe://k8s-west.acme.com/ns/staging-ns/sa/default
The "Trust domain" is the staging.acme.com or k8s-west.acme.com portion of the name, and the "Path" is the /payments/mysql or /ns/staging-ns/sa/default portion.
A simple first pass would be to allow client names to be either the full URI, or just the path portion (with a fixed Trust Domain). I'm not sure which is better yet. Since we don't support the SPIFFE name constraints, we can't be sure of trust domains being signed by the right CA, so supporting multiple trust domains is more work. Just the path may also be an easier migration from current client identities.
Maybe we need something a bit more flexible in the mapping though. Like, what if you wanted to do spiffe://mydomain.co/keywhizclients/clientname.
Hierarchical SPIFFE identities may provide a good path for multitenancy in Keywhiz as well.
I've been thinking about this, and I think I'd like to support SPIFFE in a slightly more bold manner, which also better aligns with how Keysync works:
Currently, the keywhiz data model has three objects: Clients, Groups, Secrets
Clients and Secrets are both mapped into groups, which grants those clients access to the secrets in all their groups.
I think each Keysync should only require a single mTLS identity, which grants it access to multiple clients. We create a new "node" entity. Each client is mapped to exactly 1 node, but each node may have multiple clients.
As a migration path, we can provide a backfill to create nodes 1:1 with clients.
Some fields (especially "last seen") on the client should be moved to the node, and that's also where we'd put a field for the SPIFFE identity.
We can use this to also remove some of the local keysync configuration that's required today by storing it in the node and/or client objects directly. This means new clients can be created without any client-side changes, which is a bit of a pain-point for us today. Then keysync relies only on SPIRE agent for storing persistent local state, which should improve operations for us.