Add support for external TLS renewal #87
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
October 21, 2020 15:34
By providing the --external-tls-renewal flag in combination with --in-cluster, the TLS cert is fetched from a secret but no k8s CSR api is invoked for initial request or renewal. Useful for running in i.e. OpenShift which can provide auto-renewal of service certificates. Also replaced existing file based load with this watcher implementation to automatically reload, in case the cert is volume mounted
stromnet
changed the title
|
@josselin-c any movement or updates on this one? We are running into this as well on OpenShift. |
|
To tie some threads together as an outsider, i believe #134 addresses the reload-from-disk aspect of this request. Since kubernetes secrets can be presented as files on disk that should be enough. |
|
Sounds like that yes, if I understand that change correct. pod mounts the external secret as volume and that new code ensures it is re-read automatically. Assuming the fsnotify.Watcher impl actually triggers on such "filesystem" changes, but since this usecase is what that ticket deals with I assume that also have been tested |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After following the guide on https://www.openshift.com/blog/fine-grained-iam-roles-for-openshift-applications to setup AWS integration in our OpenShift cluster, we noticed after a few weeks that the newly created CSRs where not automatically approved. Not sure if that is done on other k8s distributions, but not on OC (4.5).
An alternative solution of handling the TLS certificates is to use what OC calls "Service serving certificates", i.e. let OC generate & renew certificates, and provide them via a secret. Some more details on that particular problem here, but not really relevant for the PR: sabre1041/openshift-aws-iam-webhook-integration#3
This change adds support for the
--external-tls-renewalflag which will make the k8s Secret "readonly", i.e only read but never update it. Instead of having the k8s go-clientcertificate_manager.Managerrenew it via CSR API, it will just try to re-read it from the secret when it is is nearing expiration time.The actual implementation is pretty much a copy of the
certificate_manager.Managerimpl, but this allows delegation to a arbitrary method to "Load" it. Unfortunately the original impl does not permit re-use, so had to copy a bit..As for reading the secret, it uses the existing SecretCertStore impl.
In addition, this also adds reload support for when using external file rather than secrets (
--in-cluster=false). Actually started that way, with the secret mounted on a volume, before I decided to just read it from the secret from the code. And with the abstraction it was quite straightforward anyway.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.