Using nginx ingress controller in AKS with TLS certificate termination pulled from Key vault with workload identity

Question

I am using AKS with nginx ingress controller. I am using kubernetes tls secret that includes the .key and .crt and referencing it into the ingress.yaml

Kubectl create secret tls $secret_name --key=$file.key --cert=$file.crt

In the ingress.yaml:

Tls:
  SecretName: $secret_name

The recommended practice is to use key vault to store the certificates instead of secrets directly so it could be rotated and also avoid kubernetes secrets which are not encrypted.

The procedure is here: https://learn.microsoft.com/en-us/azure/aks/csi-secrets-store-nginx-tls

I am wondering if this really worth it because a secret is created anyway with the certificate pulled from key vault, this secret has to be references in the ingreds.yaml and can be seen with kubectl get secret as any one.

What is the gain in terms of security when using the key vault as it creates a kubernetes secret?

I want to know what you think about it?

Answer 1

Using of Azure Key Vault method is generally the better approach on comparing to Direct Use of Kubernetes Secrets

1. Using Kubernetes Secrets Directly: To use this method, you need to create a Kubernetes secret that contains the TLS certificates (.key and .crt files) and refer to it in the ingress.yaml file. This method is simple but it has some drawbacks in terms of security and manageability.

2. Using Azure Key Vault via the Secrets Store CSI Driver: A way to use TLS certificates in AKS is to store them in Azure Key Vault and then connect them to AKS with the Secrets Store CSI Driver. This way, the TLS certificates become Kubernetes secrets that AKS can access, but they are controlled and fetched from the Key Vault.

The advantages of accessing Key Vault through the Secrets Store CSI driver

• Enhanced Security: Kubernetes secrets have less security features than Azure Key Vault. Kubernetes secrets are only encoded in Base64, not encrypted, so anyone can decode them without authorization. Key Vault encrypts the secrets and provides better access controls and auditing capabilities.

• Centralized Management and Compliance: With Key Vault, you can manage secrets, keys, and certificates in a central location. This helps you comply with different regulatory standards, as you can track and record your actions.

• Automatic Rotation and Renewal: By automating the rotation and renewal of certificates, Key Vault can lower operational overhead and the risk of expired certificates.

• Reduced Exposure in Kubernetes: Although the final output is a Kubernetes secret, the exposure time of the secret within the Kubernetes environment is minimized. The secret does not need to be manually handled or stored for extended periods within the cluster.

• Integration with Azure Ecosystem: Key Vault is a convenient and efficient choice for those who already use Azure services, as it integrates seamlessly with them.

To conclude, using Azure Key Vault may appear to be redundant when a Kubernetes secret is already generated, but it offers significant advantages in security practices, automated management, and compliance. This method follows the principle of least privilege and guarantees that sensitive data is securely managed throughout its lifecycle.

The Azure Key Vault provider for Secrets Store CSI Driver and its integration with AKS. It highlights features like mounting secrets to pods, supporting multiple secret objects, and autorotation of secrets​​. These features indicate a more secure and manageable approach to handling TLS certificates in AKS, especially when compared to the traditional method of using Kubernetes secrets directly.

reference:

Set up Secrets Store CSI Driver to enable NGINX Ingress Controller with TLS on Azure Kubernetes Service (AKS) - Azure Kubernetes Service | Microsoft Learn

https://learn.microsoft.com/en-us/azure/aks/csi-secrets-store-driver

https://learn.microsoft.com/en-us/azure/aks/csi-secrets-store-configuration-options