PrivateKeyAccess Permission

[jplana]

I'm trying to implement a more restrictive approach regarding private key access. Usually, we'd like private keys not to be accessed at all, but at the same time allow users do things like requesting a cert to be signed or revoke certs.

While in the documentation I found references to such permissions (https://lemur.readthedocs.io/en/latest/administration.html#identity-and-access-management) I couldn't find any kind of implementation and currently I can't see any way of allowing a user to request a certificate without exposing him the private key.

My initial proposal would be something like jplana/lemur@f5a2c96bddc633cc3e8bfc44e026b3fec66b196c

This would require to add a new role, and add this role to every user that needs to access private keys (in this case only for PendingCertificates, but adding this restriction to issued certs would be quite easy).

Would you be interested on adding this?

[kevgliss]

I agree we shouldn't allow private keys to be exposed for pending certs. The way we have handled this in other places is through creator and owner roles:

https://github.com/Netflix/lemur/blob/master/lemur/certificates/views.py#L448

Would restricting pending_certificates to those roles work for your use case.

cc @castrapel

[jplana]

Actually I was thinking of having the very same approach for certificates (so using the very same annotation in the method you pointed out). While it might seem useful to access the private key, If we can configure destinations properly, and restrict key access, we could probably delegate a lot of tasks to a broader range of users.

[jplana]

Just to explicitly answer your question: Would restricting pending_certificates to those roles work for your use case?

Actually no, It wouldn't, as we'd like the creator or the cert not to be able to access those private keys (the keys would be finally distributed by Lemur).

[hosseinsh]

@jpartain89, I agree with the general notion of tightening access to the private key, but not all destinations are supported by Lemur, and there are the edge cases, where the cert owner/creator needs to fetch the private key and deploy it on the their end-points manually.

[jplana]

@hosseinsh I completely understand the need for it. Part of our needs come from the fact that, while in our case the destination can be automated, the source for the certificates (the issuer) needs manual interaction (emails and other docs attached), so we wanted some human trusted agents to manage (request/create/revoke) them for us. While these agents are trusted, we don't think they should access private keys.

This patch would work (or at least be helpful) if the manual private key management is really an edge case and just a few users need to deploy to those manual end-points, as you could just add the access_sensitive role to them. If the need is actually more traversal, and a lot of users need to access those endpoints, adding this role to everybody (making it the default?) would work too. The problem is that currently, without this or other similar patch, the creator of any pending certificate is automatically granted access to the private key.

Please let us know if there's any other way we could make this more acceptable for your use case.

[castrapel]

This is a great first-step, but the addition of an access_sensitive role seems excessive in that it will grant the cert owner the ability to see all of their certificates' private keys.

It seems more viable to attach a separate set of roles for private key access to the certificate. Right now, a certificate has "Roles". With the addition of a "Roles allowed to view private key" addition (This would default to being nothing, or being admin during cert creation), admins could add any existing role(s) they would like for private key viewership/export.

I think this would require the creation of a new roles -> certificates association table that would associate certificates to roles which users need to be a member of to view private key (private_key_roles)? And changing the view private key logic a bit to account for this. Thoughts?

[jplana]

@castrapel that was actually our long term plan, but probably only the first step. I'd say that instead of setting up "nothing" or "admin" during cert creation for those "Roles allowed to view private key" defaults, it would be great to make those roles be dependent on the source/destination. So if the user during certificate creation uses a specific source (or sets a specific destination), the role is automatically granted to him. That would mean that giving users access to specific sources/destinations would give them access to their privates keys as necessary. I'd say that this logic should be in the source/destinations plugin (I'm sure about the source as it's probably the only place where it makes sense, but destinations might change during cert lifecycle...)

While this is for sure the way to go, we didn't want to get into it yet as we don't really need it in our first implementation stage (we'll have a set of users that will be able to access all private keys) and these changes will probably take longer to implement than the all or nothing access_sensitive solution.

[castrapel]

Hi @jplana, our environment is vastly heterogenous as far as sources are concerned. There are many users operating in a single source that have no business viewing other private keys on that source. We have a number of users that might be confused if we started with a broad access_sensitive model and changed it to more granular private key controls after the fact. If we just implemented access_sensitive, I suspect that our Lemur support oncall would be burdened by numerous user complaints about being unable to view private key for a specific cert, and our only recourse would be to allow them to view all of the things, which would be an unfortunate fix.

I agree with you that some type of role naming syntax that allows key viewership across a source makes sense. Also, for users who need to view all of the private keys but who we don't want to make administrators, having an all-powerful private-key viewership role such as access_sensitive also makes sense. However in order for us to merge this in, we would also need the capability to specify specific roles allowed to view a certificate's private key.

Thanks, Curtis

[Jonesy22]

Did this ever get resolved? Specifically the part regarding allowing users to request certificates to be signed with an authority, but not have access to the authority's private key? If so, what are the necessary changes required to make this happen. Thanks in advance.

[hosseinsh]

Hi @Jonesy22, I don't believe users have access to an authorities private key, because they have the permission to use that Authority. The Authorities' page doesn't ever render the private key of an authority, which for most cases is not accessible to Lemur, e.g., public CAs etc.

[Jonesy22]

@hosseinsh When an authority is created, a certificate is created in the certificates view for the authority. Here, any user who has operator or admin access can view the private key. But I was wanting a user to use the authority to sign a certificate, without being able to see the key here.