Skip to content
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

Closed
jdelic opened this issue Aug 31, 2016 · 11 comments

Comments

@jdelic
Copy link

jdelic commented Aug 31, 2016

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 access postgresql/creds/foo and for CN=bar issued by "DEV Build Server 2" to access secrets/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.

@jefferai
Copy link
Member

@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.

@jefferai jefferai added this to the future milestone Aug 31, 2016
@jdelic
Copy link
Author

jdelic commented Aug 31, 2016

@jefferai:

You can use individual (non-CA) certificates already, but the policies match per certificate, not per-CN.

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 😉

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.

I agree that would be even better.

@jdelic
Copy link
Author

jdelic commented Sep 21, 2016

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

@jefferai
Copy link
Member

@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.

@sts
Copy link

sts commented May 2, 2017

@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.

@sts
Copy link

sts commented May 2, 2017

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:

Thinking about this more, I almost wonder if we should resolve the "multiple matches" problem by allowing the client to specify which role they would like to authenticate against, like in the other credential backends.

Are you also going to work on this? In this issue might be two use cases! 👍

@jefferai
Copy link
Member

jefferai commented May 2, 2017

@sts It's already done and merged!

@jefferai
Copy link
Member

jefferai commented May 2, 2017

Closing, fixed in #2595

@jefferai jefferai closed this as completed May 2, 2017
@jdelic
Copy link
Author

jdelic commented May 2, 2017

this is fantastic news!
My thanks to everyone involved and @michaelansel for implementing the PR.

@sts
Copy link

sts commented May 2, 2017

@jefferai Could you please expand a bit on how we can use the changes in #2595 for the Puppet use case?
I have a single CA (Puppet CA) which is used to sign client certificates of all Puppet agents. I'd only like to permit access for a subset of clients to certain Vault API paths, so eg. assign the web policy for all nodes matching cn =~ *web*.

@jefferai
Copy link
Member

jefferai commented May 2, 2017

@pbernal pbernal removed this from the not-scheduled milestone May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants