The recommended solution is to use Azure Workload Identity.
In order to do that, create an Azure Service Principal following the cert-manager recommendations.
Federate the Application Client ID with the cert-manager service account as explained here and add these options to your cert-manager Helm values configuration:
extraArgs: [--issuer-ambient-credentials=true]
serviceAccount:
annotations:
azure.workload.identity/client-id: <<your-application-client-id>>
Once your cert-manager is configured this way, create the following Issuer
in the okteto
namespace:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: okteto-letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: "<<your-email>>"
privateKeySecretRef:
name: okteto-letsencrypt-acme
solvers:
- http01:
ingress:
serviceType: ClusterIP
class: nginx
- dns01:
azureDNS:
clientID: "<<your-application-client-id>>"
subscriptionID: "<<your-subscription-id>>"
tenantID: "<<your-tenant-id>>"
resourceGroupName: "<<resource-group-name>>"
hostedZoneName: "<<your-okteto-subdomain>>"
environment: AzurePublicCloud
and the following Certificate:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: okteto-letsencrypt
spec:
secretName: okteto-letsencrypt
duration: 8760h0m0s
renewBefore: 600h0m0s # 25d
issuerRef:
name: okteto-letsencrypt
kind: Issuer
dnsNames:
- "*.<<your-okteto-subdomain>>"
Now, add the following to your Okteto Helm configuration file to tell Okteto and NGINX to use your certificate:
wildcardCertificate:
create: false
name: okteto-letsencrypt
ingress-nginx:
controller:
extraArgs:
default-ssl-certificate: $(POD_NAMESPACE)/okteto-letsencrypt
Finally, upgrade your Okteto installation for the new configuration to be applied.
For troubleshooting, you can check the cert manager logs, and the events associated to the resources Challenge
, Order
and CertificateRequest
.