-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Delete user k8s, etc. certificates on re-issue #6492
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried the proposed logic is incorrect as it assumes the impact of a role change to be limited to a single cluster whereas I think a role change should discard certs cached for all clusters so that requests against any cluster would trigger a reissue with the new roles.
Further, since SSH certs are now also cached per cluster, they should get discarded with the other service certs as well.
From wading around in I'm not sure of the best way forward with this. Maybe the correct thing is to stop trying to cobble together a solution out the existing key management primitives, and write something that:
|
@awly's suggestion to go back to unconditionally deleting the certificates without
I've added this to the ProxyClient as the cache cleanup needs to happen before the re-issued Given that the rest of the system currently expects the new certs to be in the key store before |
eff061a
to
bb2916a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, does this really work as intended since it doesn't seem to be performing any real deletion of the stored certs anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bot.
Prior to this change, user certificates for services like kubernetes were preserved across a certificate re-issue. This led to issues where elevated privileges granted by an access request were not applied to the service certificates as they were not updated during the reissue process. This patch changes the certificate re-issue process such that: * certificates for services (like Kuberenetes) are not preserved over a certificate re-issue. It is expected that they will be recreated on the first access to the service in question, and * the local keystore files for these certificates services are explicitly deleted so that the now-invalid cached certificates are not returned on keystore queries. See-Also: #5047
Andrew's feedback that it's OK delete the cached certificates without checking for a role change simplifies everything. This, hopefully last, patch makes the following changes - Deletes all of the role change detection code - Adds a parameter to ReissueUserCerts that indicates how existing certificates in the cache should be treated (i.e. Kept or Dropped) - Adds code to ProxyClient.reissueUserCerts() that takes the appropriate cache action. I've added this to the ProxyClient as the cache cleanup needs to happen _before_ the new key is added to the key store, otherwise it becomes very difficult to differentiate between the old certificates that need purging and new certs that need to be preserved. Given that the rest of the system currently expects the new certs to be in the key store before ProxyClient.reissueUserCerts() returns, this looked like the minimal change required to add the desired behaviour.
Co-authored-by: Andrej Tokarčík <[email protected]>
e53b7df
to
8643e16
Compare
Delete user k8s, etc. certificates on re-issue Prior to this change, user certificates for services like kubernetes were preserved across a certificate re-issue. This led to issues where elevated privileges granted by an access request were not applied to the service certificates as they were not updated during the reissue process. This patch changes the certificate re-issue process such that: * certificates for services (like Kuberenetes) are not preserved over a certificate re-issue. It is expected that they will be recreated on the first access to the service in question, and * the local keystore files for these certificates services are explicitly deleted so that the now-invalid cached certificates are not returned on keystore queries. See-Also: #5047
Delete user k8s, etc. certificates on re-issue Prior to this change, user certificates for services like kubernetes were preserved across a certificate re-issue. This led to issues where elevated privileges granted by an access request were not applied to the service certificates as they were not updated during the reissue process. This patch changes the certificate re-issue process such that: * certificates for services (like Kuberenetes) are not preserved over a certificate re-issue. It is expected that they will be recreated on the first access to the service in question, and * the local keystore files for these certificates services are explicitly deleted so that the now-invalid cached certificates are not returned on keystore queries. See-Also: #5047
Prior to this change, user certificates for services like kubernetes were
preserved across a certificate re-issue. This led to issues where elevated
privileges granted by an access request were not applied to the service
certificates as they were not updated during the reissue process.
This patch changes the certificate re-issue process such that:
over a certificate re-issue. It is expected that they will be recreated
on the first access to the service in question, and
deleted so that the now-invalid cached certificates are not returned
on keystore queries.
See-Also: #5047