-
Notifications
You must be signed in to change notification settings - Fork 333
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
An Azure AKS + Let's Encrypt Tutorial #1120
An Azure AKS + Let's Encrypt Tutorial #1120
Conversation
✅ Deploy Preview for cert-manager-website ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
643a24d
to
ee86856
Compare
AZWI can be installed as a first class feature of AKS using the |
Also FWIW, I think most people may be used to specifying the managed identity's clientID using the ServiceAccount annotation. The value on the CRD is meant to act as an override for cases where you are dealing with multiple DNS zones that need different MSI's for access (though it can work perfectly fine this way). I pushed for that feature to be added to the PR so that there was parity with pod-identity and so that cert-manager behaved similarly to other applications that have already added AZWI support. Personally, I only need interaction with one DNS zone per cluster, so specifying the clientId as a ServiceAccount annotation and omitting the Maybe include an example of both ways? One using the annotation only and another example for "configuring cert-manager to use multiple DNS zones requiring different MSI's"? |
--node-count 1 \ | ||
--node-vm-size "Standard_B2s" \ | ||
--load-balancer-sku basic \ | ||
--enable-oidc-issuer # ℹ️ This is required for workload identity federation and is only available when using the aks-preview extension. |
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 for writing the detailed docs! I'll try to have a closer look at the document soon.
There's a tiny thing that I've just spotted:
- OIDC issuer has been promoted to GA in AKS 2022-10-16, so I think the
aks-preview
extension is no longer a requirement for that.
--enable-oidc-issuer # ℹ️ This is required for workload identity federation and is only available when using the aks-preview extension. | |
--enable-oidc-issuer # ℹ️ This is required for workload identity federation. |
aks-preview
is definitely needed when Workload Identity Webhook itself is installed as a preview extension, not sure if it's mandatory for running az identity federated-credential create
assuming the webhook is installed through a chart.
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.
Done.
Thanks both of you for the feedback. I've updated the tutorial to use the --enable-workload-identity flag, |
--node-vm-size "Standard_B2s" \ | ||
--load-balancer-sku basic \ | ||
--enable-oidc-issuer \ | ||
--enable-workload-identity # ℹ️ This is currently only available when using the aks-preview extension. |
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 think it'd be useful to mention that if EnableWorkloadIdentityPreview
feature flag is not yet enabled for the subscription, a user will have to follow these steps: https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster#register-the-enableworkloadidentitypreview-feature-flag
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.
Done.
fce5700
to
65c36a5
Compare
This comment was marked as outdated.
This comment was marked as outdated.
@pinkfloydx33 I didn't have the energy to document client-id both ways. |
Fine by me, makes sense. Like I said, not sure what the common case will be. |
--wait \ | ||
--namespace cert-manager \ | ||
--set installCRDs=true \ | ||
--set-string 'serviceAccount.labels.azure\.workload\.identity/use=true' # ❗ Label the cert-manager service account for the attention of workload-identity webhook |
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.
There's upcoming change in workload identity webhook, which would require the label to rather be set on pods (Azure/azure-workload-identity#601). For the transition period, any of those would work (serviceAccount or pod label: https://github.com/Azure/azure-workload-identity/blob/df6362a239c5d3fc19f48ff8bc7ae2ced594f116/pkg/webhook/webhook.go#L136). Since we never know which version of the webhook is installed in a cluster, I guess we can make the example universal by simply setting the label in two places.
--set-string 'serviceAccount.labels.azure\.workload\.identity/use=true' # ❗ Label the cert-manager service account for the attention of workload-identity webhook | |
--set-string 'podLabels.azure\.workload\.identity/use=true' \ | |
--set-string 'serviceAccount.labels.azure\.workload\.identity/use=true' # ❗ Label the cert-manager service account and pod for the attention of workload-identity webhook |
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.
Done. I've moved these to a separate values.yaml file for easier readability.
6e7ded7
to
89a41fd
Compare
@@ -0,0 +1,6 @@ | |||
# values.yaml | |||
podLabels: | |||
azure.workload.identity/use: "true" |
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.
azure.workload.identity/use: "true" | |
azure.workload.identity/use: "true" |
The indentation is a bit off, the rest looks great :)
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.
Done.
89a41fd
to
0f36191
Compare
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
…ndex page Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
0f36191
to
b202db5
Compare
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
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.
@SgtCoDFish I think I addressed all your code review comments.
PTAL
...g-started-with-cert-manager-on-azure-kubernetes-service-using-lets-encrypt-for-ssl/README.md
Outdated
Show resolved
Hide resolved
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
/approve
/hold
I've added a couple of suggestions - should've thought about the embedded file thing before. Happy to merge as-is, but added a hold in case you'd like to embed the files!
Add it to `next-docs` | ||
Add it to `docs/` but branch from the [`release-next` branch](https://github.com/cert-manager/website/tree/release-next) and merge the PR into that branch. |
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.
Great drive-by improvement 👍
```yaml | ||
# certificate.yaml | ||
apiVersion: cert-manager.io/v1 | ||
kind: Certificate | ||
metadata: | ||
name: www | ||
spec: | ||
secretName: www-tls | ||
privateKey: | ||
rotationPolicy: Always | ||
commonName: www.$DOMAIN_NAME | ||
dnsNames: | ||
- www.$DOMAIN_NAME | ||
usages: | ||
- digital signature | ||
- key encipherment | ||
- server auth | ||
issuerRef: | ||
name: selfsigned | ||
kind: ClusterIssuer | ||
``` | ||
🔗 <a href="certificate.yaml">`certificate.yaml`</a> |
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.
suggestion: I don't think it's required for you to do this, but seeing this just triggered a memory for me of one of the benefits of the website migration - embedding YAML files.
See for example the old ACME tutorial (which maybe should be a redirect to your newer/better one, but that's a task for another day) here.
(Which produces this page)
That would ensure that the YAML in this document doesn't get out of sync with the YAML in certificate.yaml.
I like that you've got an explicit link to it as well as embedding it, in any case!
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.
Done. In #1140
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 didn't know about that feature. Thanks.
``` | ||
helm upgrade cert-manager jetstack/cert-manager \ | ||
--namespace cert-manager \ | ||
--reuse-values \ | ||
--values values.yaml |
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.
nit (non-blocking): missing a tag for the code block, but it doesn't really matter!
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.
Done #1140
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SgtCoDFish, 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 |
Should also say that I've not tested this (no Azure env) but I think it looks awesome! |
/hold cancel |
Preview: https://deploy-preview-1120--cert-manager-website.netlify.app/docs/tutorials/getting-started-with-cert-manager-on-azure-kubernetes-service-using-lets-encrypt-for-ssl/
Written during the course of testing cert-manager/cert-manager#5570