Skip to content

Latest commit

 

History

History
54 lines (34 loc) · 3.95 KB

02-ca-certificates.md

File metadata and controls

54 lines (34 loc) · 3.95 KB
Raw

Generate Your Client-Facing and AKS Ingress Controller TLS Certificates

Now that you have the prerequisites met, follow the these steps to create the TLS certificates that Azure Application Gateway will serve for clients connecting to your workload as well as the certificate your Kubernetes ingress controller will expose. If you already have access to appropriate certificates, or can procure them from your organization, consider doing so and skipping the certificate generation steps. The following will describe using a self-signed certs for instructive purposes only.

Expected results

To support end-to-end TLS encryption, the following TLS certificates are procured.

Common Name Purpose Notes
bicycle.contoso.com Attached to the public IP on the Application Gateway This is client-facing for the endpoint your workload will respond at. Typically this will be an EV certificate generated by a public CA.
*.aks-ingress.contoso.com Attached to the ingress controller in the cluster This is not client-facing and doesn't need to be procured by a public CA. This provides TLS encryption between Application Gateway and your ingress controller.

⚠️ Do not use the certificates created by these instructions for actual deployments. The use of self-signed certificates are provided for ease of illustration purposes only. For your cluster, use your organization's requirements for procurement and lifetime management of TLS certificates, even for development purposes.

📓 For more information, see Azure Architecture Center guidance for PCI-DSS 3.2.1 Requirement 3.6 in AKS and TLS encryption architecture considerations.

Steps

  1. Create the certificate for Azure Application Gateway with a common name of bicycle.contoso.com.

    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -out appgw.crt -keyout appgw.key -subj "/CN=bicycle.contoso.com/O=Contoso Bicycle" -addext "subjectAltName = DNS:bicycle.contoso.com" -addext "keyUsage = digitalSignature" -addext "extendedKeyUsage = serverAuth"
openssl pkcs12 -export -out appgw.pfx -in appgw.crt -inkey appgw.key -passout pass:

  2. Base64 encode the client-facing certificate.

    💡 No matter if you used a certificate from your organization or you generated one from above, you'll need the certificate (as .pfx) to be Base64 encoded for proper storage in Key Vault later.

    APP_GATEWAY_LISTENER_CERTIFICATE_BASE64=$(cat appgw.pfx | base64 | tr -d '\n')

  3. Generate the certificate for the ingress controller with a common name of *.aks-ingress.contoso.com.

    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -out ingress-internal-aks-ingress-contoso-com-tls.crt -keyout ingress-internal-aks-ingress-contoso-com-tls.key -subj "/CN=*.aks-ingress.contoso.com/O=Contoso AKS Ingress"

# Combined as PEM structure (required by Azure Application Gateway for backend pools)
cat ingress-internal-aks-ingress-contoso-com-tls.crt ingress-internal-aks-ingress-contoso-com-tls.key > ingress-internal-aks-ingress-contoso-com-tls.pem

  4. Base64 encode the ingress controller certificate.

    💡 No matter if you used a certificate from your organization or you generated one from above, you'll need the public certificate (as .crt or .cer) to be Base64 encoded for proper storage in Key Vault later.

    INGRESS_CONTROLLER_CERTIFICATE_BASE64=$(cat ingress-internal-aks-ingress-contoso-com-tls.crt | base64 | tr -d '\n')

Next step

▶️ Prep for Microsoft Entra integration