Profile Applicability:
Level 2
Description:
Storing secrets directly within Kubernetes should be avoided when possible. Instead, consider using an external secret storage solution, such as Azure Key Vault, HashiCorp Vault, or any other third-party secret management system. External secret storage provides better security, management, and auditability for sensitive data such as API keys, passwords, and certificates.
Rationale:
Storing secrets in Kubernetes using Secrets objects is convenient but not always the most secure option, as these secrets are stored unencrypted by default (unless explicitly encrypted at rest). External secret storage solutions provide additional layers of encryption, access control, auditing, and integration with other services, reducing the risk of exposing sensitive information.
Impact:
Pros:
Provides better security by storing secrets in an external, managed service with advanced encryption and access controls.
Improves auditability and monitoring of secret access and usage.
Centralizes secret management for easier management across multiple environments and clusters.
Cons:
Additional setup and configuration effort required to integrate Kubernetes with external secret storage.
May increase latency due to the need for querying external systems for secrets.
Default Value:
By default, Kubernetes stores secrets within the cluster itself using the Secret resource, which may not offer the same level of security as external secret management solutions.
Pre-requisites:
Ensure that an external secret management system is configured and accessible from your Kubernetes cluster. Integrate Kubernetes with the external system to securely manage secrets.
Remediation
Test Plan:
Using Azure Console:
Navigate to the Azure portal and review any existing integration between your Azure Kubernetes Service (AKS) cluster and Azure Key Vault (or other external secret storage systems).
Verify if the AKS cluster is set up to retrieve secrets from an external secret store rather than relying solely on Kubernetes-native secrets.
Using Azure CLI:
Use the following command to check if Azure Key Vault is configured for secret management:
az aks show --resource-group <resource-group-name> --name <aks-cluster-name> --query "addonProfiles.azureKeyvaultSecretsProvider.enabled"
Ensure that the azureKeyvaultSecretsProvider is enabled and configured for use.
Implementation Plan:
Using Azure Console:
Navigate to Azure Key Vault in the Azure portal and create a Key Vault if not already created.
In the Azure portal, go to your AKS cluster and set up integration with Azure Key Vault by enabling the Azure Key Vault Secrets Provider.
Update the Kubernetes manifests to reference secrets from Azure Key Vault instead of Kubernetes Secrets.
Using Azure CLI:
Set up Azure Key Vault and create the required secrets in Azure Key Vault:
az keyvault create --name <keyvault-name> --resource-group <resource-group-name>
Enable the Azure Key Vault Secrets Provider in AKS by running the following command:
az aks enable-addons --resource-group <resource-group-name> --name <aks-cluster-name> --addons azure-keyvault-secrets-provider
Update your Kubernetes deployment or pod specs to use Azure Key Vault for secret retrieval by defining the AzureKeyvaultSecretsProvider in your manifest.
Backout Plan:
Using Azure Console:
If the integration with external secret storage causes issues, you can revert to storing secrets within Kubernetes by disabling the Azure Key Vault Secrets Provider in the Azure portal.
Using Azure CLI:
Revert the changes by disabling Azure Key Vault Secrets Provider with the following command:
az aks disable-addons --resource-group <resource-group-name> --name <aks-cluster-name> --addons azure-keyvault-secrets-provider
Restore Kubernetes-native secrets if needed.