Modify the shield helm chart to work with cert-manager #2325
Conversation
This file contains hidden or 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
The certificates in the shield helm charts do not play nicely with argocd. Since argocd will essentially call "helm template" to acquire the chart's yaml, the "lookup" function will never work, and the certificate generation will create a different certificate each time. It's possible to tell ArgoCD to ignore this ever-changing certificate, but this also means that the certificate will never be rotated. The most graceful solution to this is to integrate with the widely-used cert-manager project. See https://github.com/cert-manager/cert-manager The idea is that you can create a certificate chain using cert-manager, and then refer to those certificate in the helm chart instead of asking the helm chart to generate them. For our ppurposes there are two interesting cert-manager resources. The "Issuer" is a resource that is used to sign a certificate. A "Certificate" is actually a request to create an x509 certificate. It emits a k8s Secret containing the actual TLS certificate details. See: * https://cert-manager.io/docs/concepts/issuer/ * https://cert-manager.io/docs/usage/certificate/ Imagine that the customer has the following setup: * A) a "self-signed" root Issuer * B) a "CA" Certificate representing the root (using A above). It will be long-lived, like all root CAs are. * C) a "root cert" Secret containing the actual x509 root CA cert (created by cert-manager as a result of B) * D) a "CA" Issuer that uses the Secret from C above At this point there is a long-lived root x509 certificate as well as an Issuer that will create certificates signed by that root. At this point, the shield helm chart can include a Certificate resource that refers to the Issuer from step D above. This will generate a Secret with the actual x509 cert. This secret can be used by the shield Deployment for the TLS webhook port. Additionally, the validating webhook can refer to the CA Certificate resource from step B above. It uses an annotation that tells cert-manger to edit the webhook and insert the appropriate caBundle information.
|
Hi @yoderme. Thanks for your PR. After inspecting your changes someone with write access to this repo needs |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR title does not comply with regex: ^(\w*)(?:\(([\w\$\.\,\-\*\s]*)\))?\:\s?(.*)$!
Check PR guidelines at https://github.com/sysdiglabs/charts/blob/main/README.md#pull-requests
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.
The certificates in the shield helm charts do not play nicely with argocd. Since argocd will essentially call "helm template" to acquire the chart's yaml, the "lookup" function will never work, and the certificate generation will create a different certificate each time.
It's possible to tell ArgoCD to ignore this ever-changing certificate, but this also means that the certificate will never be rotated.
The most graceful solution to this is to integrate with the widely-used cert-manager project. See
https://github.com/cert-manager/cert-manager
The idea is that you can create a certificate chain using cert-manager, and then refer to those certificate in the helm chart instead of asking the helm chart to generate them.
For our ppurposes there are two interesting cert-manager resources. The "Issuer" is a resource that is used to sign a certificate. A "Certificate" is actually a request to create an x509 certificate. It emits a k8s Secret containing the actual TLS certificate details.
See:
Imagine that the customer has the following setup:
At this point there is a long-lived root x509 certificate as well as an Issuer that will create certificates signed by that root.
At this point, the shield helm chart can include a Certificate resource that refers to the Issuer from step D above. This will generate a Secret with the actual x509 cert. This secret can be used by the shield Deployment for the TLS webhook port.
Additionally, the validating webhook can refer to the CA Certificate resource from step B above. It uses an annotation that tells cert-manger to edit the webhook and insert the appropriate caBundle information.