-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
RFE: allow common name matching for policy assignment with TLS certificate auth backend #1823
Comments
@jdelic You can use individual (non-CA) certificates already, but the policies match per certificate, not per-CN. This RFE discusses a granularity that sits somewhere in between (since you can issue multiple certs with the same CN), but just FYI. If an enhancement like this goes in, it'd be good to add more potential matches too -- not just CN but any DNS SAN, IP SAN, etc. |
Yeah, I know... but I'm trying to minimize manual configuration as much as possible. Since Vault needs to be unsealed after it has been brought up in a deployment environment before it can be configured, manual configuration is necessary (i.e. Puppet can't do it). So bringing up an environment and then logging in once to install the root CAs in the Vault server is expected, but reconfiguring Vault manually for every single issued certificate is impossible 😉
I agree that would be even better. |
For further background information on why I'd like this change, I have since documented my current approach here: https://github.com/jdelic/saltshaker/blob/master/CERTIFIED_BUILDS.md |
@jdelic The benefits are obvious, no further background needed :-) Just need to find the time to do this, which on my end will not be soon, unfortunately, so anyone that wants to actually code this should get in touch. |
@jefferai another use case for this RFE would be to reuse the Puppet PKI for authentication of Vault clients as this PKI is already in place for most environments. This elegantly factors out the key distribution process, as signing agent certificates is already part of a standard workflow for Puppet users. |
Looks like someone is already working on getting support to limit authentication for certain CNs only for Vault 0.7.1. @michaelansel you mentioned something in your latest pull-request #2595:
Are you also going to work on this? In this issue might be two use cases! 👍 |
@sts It's already done and merged! |
Closing, fixed in #2595 |
this is fantastic news! |
@jefferai Could you please expand a bit on how we can use the changes in #2595 for the Puppet use case? |
See the |
Some background
Currently I use Vault's PKI secret backend to issue a SSL client certificate for each build on my continuous delivery server, using a separate root CA for each deployment environment (dev/staging/live) with an intermediate CA for each build server. Services on each environment are configured to trust that environment's root CA. This was enough, since most services enabling SSL client authentication use the CN attribute of the distinguished name as a username replacement, thereby allowing me to limit access to resources that way.
Now I'm exploring moving to deploy Vault to the environments and manage most resources (like database access) through it for better auditing.
Vault, however, binds policies to CAs when using the TLS certificate auth backend. This means, that if I want to limit access to Vault resources (like the PostgreSQL secret backend) and have the deployed application authenticate with Vault using a client certificate, I now need one root CA per application per environment with an intermediate CA per build server. Not impossible, but it feels clunky.
Possible solution
Extend the TLS certificate authentication backend to bind policies not only to CA certificates, but also to DN attributes, or at least the CN. This way I could allow clients presenting a valid client certificate by the intermediate CA "DEV Build Server 1" for
CN=foo
to accesspostgresql/creds/foo
and forCN=bar
issued by "DEV Build Server 2" to accesssecrets/gpg/bar_passphrase
. In other words: for 3 environments and 2 build servers and 2 applications I'd need 9 CAs. If I were willing to move the CAs private keys around between the Vault instances on the build servers, I could reduce that to 6 CAs.Currently my workaround is to have a root CA "myapp DEV" create an intermediate "myapp DEV Build Server 1" which issues the client certificates and then bind the policies in DEV Vault to the "myapp DEV" CA. In other words: for 3 environments and 2 build servers and 2 applications I need 18 CAs. If I were willing to move the CAs' private keys around between the Vault instances on the build servers, I could reduce that to 12 CAs.
tl;dr
Being able to match CNs on TLS client certificates to policies would really reduce complexity in my setup.
edit: apparently, I can't math or count today.
The text was updated successfully, but these errors were encountered: