-
Notifications
You must be signed in to change notification settings - Fork 335
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
docs: Certificate Defaults Tutorial #1279
docs: Certificate Defaults Tutorial #1279
Conversation
✅ Deploy Preview for cert-manager-website ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for cert-manager-website ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@wallrj I added you for review as we started this exploration together so would be great to get your review here. |
/hold |
Had a session with Mael and we went through the demo, I have a list of actions to neated & improve the flow:
|
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.
Some initial comments. I haven't finished going through the tutorial yet.
revisionHistoryLimit: 44 | ||
secretName: test-revision-override-cert | ||
``` | ||
|
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.
Stopping here.
- All those commands above work well.
- I spotted another typo.
- Perhaps this first part of the content can be merged now and the content below can be added to a separate PR after 1.13 is released with your fix for the mutating webhook.
- Maybe write something about what "sane defaults" are recommended by the cert-manager team and explain why those are not the out-of-the-box defaults....here or in another PR?
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.
Maybe write something about what "sane defaults" are recommended by the cert-manager team and explain why those are not the out-of-the-box defaults....here or in another PR?
I love that - will add a section. Might need your input after my first draft
Perhaps this first part of the content can be merged now and the content below can be added to a separate PR after 1.13 is released with your fix for the mutating webhook.
I have another section to add with ingress-shim. So I'll see when I complete this, probably after 1.13 so I can clean up that setion, or make reference to.. run 1.13 or read here ..
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.
In the latest revision I am now able to move the <= v1.13 stuff to an appendix to make the tutorial flow better.
Added v1.14.X as a req for the tutorial.
Content is now done and ready for a full review!
@maelvls / @wallrj the only thing I have not done is to change the file reference to be GitHub links. Eg. kubectl apply -f yamls/cert-test-revision.yaml --dry-run=server -o yaml | diff -uZ yamls/cert-test-revision.yaml -
# This could be ..
kubectl apply -f https://raw.githubusercontent.com/cert-manager/website/a6c1ac93ed6b50c4bde8181b2b71f0ec53ee8841/content/docs/tutorials/certificate-defaults/yamls/cert-test-revision.yaml --dry-run=server -o yaml | diff -uZ https://raw.githubusercontent.com/cert-manager/website/a6c1ac93ed6b50c4bde8181b2b71f0ec53ee8841/content/docs/tutorials/certificate-defaults/yamls/cert-test-revision.yaml - The other concern if to have that URL variablised to point to the "preview" or commit version, and then update to "master" or latest once this is merged. Without another PR. Eg. I am happy to not do this, because the command is a bit ugly with URLs. Maybe a better idea would be to pull the |
/unhold |
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.
A couple of drive by remarks, but I'll do a more thorough review next week if you want.
- I think it might be great to start with a "Use Cases" section E.g.
In this tutorial you will learn how to use Kyverno ClusterPolicy to encourage or to enforce best-practice and policy compliant settings for cert-manager Certificate resources.
Here are a few examples, but you can adapt these to meet your own specific requirements.You want to avoid or ensure that CertificateRequest resources get cleaned up
Use a ClusterPolicy to set a sane default value for the
Certificate.Spec.RevisionHistoryLimit
field or to always override that field with1
or0
.
You want to help your users choose secure default key settings for their Certificate resources.
Use a ClusterPolicy to set policy compliant default values for the
Certificate.Spec.PrivateKey
fields
or enforce your policy by overriding those settings.
- I still think this document reads too much like a technical exploration, and that it can be made to sound more like a tutorial.
Hey, it looks like we are very close of having your tutorial published! How can I help? |
482d0c9
to
1ae8688
Compare
Based on my Q in the CNCF kyverno slack here,
It seems it was removed in 3.1.1 of kyverno, so I need to reference the logs instead. |
When the existing cert-manager `MutatingWebhookConfiguration` runs it will add the required field with an empty value, such as: `secretName: ""`, if there is no value in a required field. | ||
The consequence of this action is that our Kyverno policies will not apply as an empty value is already present. | ||
|
||
Starting at v1.14.X the cert-manager-webhook `MutatingWebhookConfiguration` resource has been scoped back to only affect `CertificateRequest` resource. |
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.
Starting at v1.14.X the cert-manager-webhook `MutatingWebhookConfiguration` resource has been scoped back to only affect `CertificateRequest` resource. | |
Starting with v1.14.x, the cert-manager-webhook `MutatingWebhookConfiguration` resource has been scoped to only affect `CertificateRequest` resources. |
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.
Agreed with the sentence. Left the .X
in the version to keep consistency across the document though.
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 should have called it out earlier, I prefer lowercase .x
throughout.
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 just thought, should I not just use v1.14
rather than v1.14.x
?
Todo
|
@jsoref thank you for all the time reviewing the changes. I resolved all the "simple" or accepted changes and left a few open where I had comments. Please let me know if there's anything I missed that you consider a show stopper. I think anything left is pretty minor. |
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.
Thanks Peter.
I left a few suggestions below but this tutorial is going to be really nice.
Maybe rebase this on release-next branch and add some of your appendix notes to the release-notes-1.14.md document.
In the `note` section you can identify that it was applied to the `Certificate` resource that was created by cert-manager based on the `Ingress` resource that we applied. | ||
|
||
Whilst you are not able to default the `secretName` and `issuerRef` fields when using the ingress-shim, you can default all other fields. | ||
This is reasonable given that the `Ingress` specification needs to know what `Secret` to mount to the ingress controller. |
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.
This makes it sound like a short-coming when in fact it seems like a benefit that the secretName and issuerRef defaulting policy do not interfere with ingress-shim Certificate resources.
I'd be tempted to remove the content from here up to "You can optionally validate that only the "0-mutate-certificate-defaults" ClusterPolicy
has been applied".
I don't think it needs mentioning
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've reworded it. My objective was that despite the Ingress part of this guide being after the defaulting of required fields, the rules for requried fields don't really play a part in the ingress section.
I hope the newer wording does a better job of explaining that.
|
||
> **Note**: The `ClusterIssuer` can be defaulted by supplying an install time parameter to cert-manager. | ||
> See [cert-manager documentation](../../usage/ingress.md#optional-configuration) for full details. | ||
> You would still need to provide at least one annotation, however this time it is static and doesn't need to be defaulted. |
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 find this a slightly confusing side note too. It doesn't seem relevant.
I suggest removing it.
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.
Yes, I was thinking that this optional configuration was worth a mention, in that you could reduce a user's knowledge of Issuer
and ClusterIssuers
further by using just the kubernetes.io/tls-acme: "true"
as opposed to the one I used here: cert-manager.io/cluster-issuer: "our-corp-issuer"
But again that's sort of an addendum to the tutorial and not really the core focus here.
Perhaps this is more operational best practice as the access to resources could tie into RBAC and how the platform team manages to Certificate provisioning lifecycle.
``` | ||
🔗 <a href="cert-test-minimal.yaml">`cert-test-minimal.yaml`</a> | ||
|
||
With these policies we achieved our objective and have enabled users to submit minimal `Certifiate` resources, with only a single field contained within the specification, the `dnsNames` entry. |
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.
This objective was not declared in the use-cases section above.
I suggest moving or copying it there.
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.
Just trying to word this as an additional use case:
- **To enable users to request a certificate by providing only a domain name**
Use a `ClusterPolicy` to set all other required `Certificate.spec` fields.
Would that suggestion cover it. Or should I be specific here and word it as:
- **To enable users to request a certificate by providing only a `Certificate.spec.dnsNames` field**
Use a `ClusterPolicy` to set all other required `Certificate.spec` fields that cert-manager expects for `CertificateRequest` creation.
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 am also struggling to come up with a good sentence. Maybe something more general, like:
Make application developers lives easier by allowing them to create secure X.509 TLS certificates with the minimum of configuration.
The application developer only needs to supply the field values that are relevant for their application, such as DNS names, extended usages and the target Secret name.
UseClusterPolicy
to set all the other requiredCertificate.spec
fields to sane defaults.
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.
Make application developers' lives easier by allowing them to create secure X.509 TLS certificates with the minimum of configuration.
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.
Thanks, I took that title and added some sub-context.
TY @wallrj - I have run out of steam and time today. I'll look to address those comments on Friday. |
Yes, that is my reasoning. Otherwise we will have to delay merging this tutorial until we release 1.14. |
|
||
1. Apply the policy to the cluster and check that it is ready: | ||
|
||
```shell | ||
kubectl apply -f cpol-mutate-certificate-defaults.yaml | ||
kubectl apply -f cpol-mutate-certificates-0.yaml | ||
kubectl get cpol | ||
``` | ||
|
||
When the `ClusterPolicy` is ready the output should look like this: | ||
|
||
```log | ||
NAME BACKGROUND VALIDATE ACTION READY AGE MESSAGE |
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.
did this line really not change its formatting to match the next line?
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.
Just fixed a couple minor CI fails and I'll check the latest preview deploy.
I do need to redo the output examples anyway due to the condensing of policies into one file.
bca8a1c
to
b4efce6
Compare
bf8ebe9
to
3c021a1
Compare
Signed-off-by: Peter Fiddes <[email protected]>
3c021a1
to
111a387
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.
Thanks @hawksight
All the latest changes look good to me and thanks for rebasing on release-next.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: wallrj The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
For further background reading around setting "defaults" or "presets", you can refer to [issue 2239](ttps://github.com/cert-manager/cert-manager/issues/2239). | ||
This tutorial came out of an investigation of that issue. |
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.
Broken link to CertificatePresets issue
@hawksight I just noticed this broken link while reading the live docs.
Sorry I missed it during review.
Tutorial on setting Certificate Defaults based off of the exploration here from the original cert-manager issue.
Preview: https://deploy-preview-1279--cert-manager-website.netlify.app/docs/tutorials/certificate-defaults/