In today’s cloud-native landscape, securely managing secrets is crucial for protecting sensitive information such as API keys, passwords, and certificates. Kubernetes, the orchestration platform of choice for many, provides a built-in mechanism for handling secrets, but this solution has limitations, particularly in environments requiring high security and compliance. When integrated with Kubernetes, AWS Secrets Manager offers a robust solution to these challenges. This guide will walk you through securing Kubernetes secrets using AWS Secrets Manager.
Why Kubernetes Secrets Management is Crucial
Kubernetes Secrets are a native way to store and manage sensitive information in your cluster. However, secrets stored directly in Kubernetes are base64-encoded and not encrypted by default, making them vulnerable to unauthorized access. Managing these secrets securely ensures that sensitive data is always protected. AWS Secrets Manager provides a more secure and centralized way to manage these secrets, offering features such as automatic rotation, fine-grained access control, and integration with other AWS services.
Setting the Foundation for Success: Prerequisites and Requirements
Before diving into the integration process, ensure your environment is set up correctly. You will need the following:
- A Kubernetes cluster running on AWS (EKS or a self-managed cluster)
- AWS CLI configured with appropriate permissions
- Helm installed on your local machine or in your CI/CD pipeline
- IAM roles configured for managing access to AWS Secrets Manager
- Kubernetes configured with kubectl access
Deploying Secrets Manager CSI Driver with Helm: Bridging Kubernetes and AWS
The Secrets Manager Container Storage Interface (CSI) driver allows Kubernetes to retrieve secrets directly from AWS Secrets Manager. To install the driver using Helm, follow these steps:
helm repo add aws-secrets-manager https://aws.github.io/secrets-store-csi-driver-provider-aws
helm repo update
helm install secrets-store-csi-driver aws-secrets-manager/secrets-store-csi-driver –namespace kube-system
This command deploys the CSI driver into your Kubernetes cluster, enabling it to interface with AWS Secrets Manager.
Verifying Installation: Ensuring Everything is in Place
After installation, verify that the Secrets Manager CSI driver is running correctly. You can do this by checking the pods in the kube-system namespace:
kubectl get pods -n kube-system
Look for the secrets-store-csi-driver pod and ensure it is in the Running state.
Introducing Secrets Manager CSI Provider for AWS: Fetching Secrets
The CSI provider for AWS is responsible for fetching secrets from AWS Secrets Manager and injecting them into your Kubernetes pods. To install this provider:
helm install aws-secrets-provider aws-secrets-manager/secrets-store-csi-driver-provider-aws –namespace kube-system
This command adds the necessary components to allow your Kubernetes cluster to interact with AWS Secrets Manager.
Creating and Managing Test Secrets in AWS Secrets Manager
To test the integration, create a secret in AWS Secrets Manager:
aws secretsmanager create-secret –name MySecret –secret-string ‘{“username”:”admin”,”password”:”password123″}’
This command stores a test secret in AWS Secrets Manager, which we will later retrieve in Kubernetes.
IAM Role Configuration: Granting Access to Kubernetes
Kubernetes needs permission to access the secrets stored in AWS Secrets Manager. Create an IAM policy with the required permissions and attach it to an IAM role:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “secretsmanager:GetSecretValue”,
“Resource”: “arn:aws:secretsmanager:region:account-id:secret:MySecret”
}
]
}
Attach this policy to an IAM role your Kubernetes service account will assume.
Service Account Setup: Enabling Secret Retrieval
Next, create a Kubernetes service account and associate it with the IAM role:
eksctl create iamserviceaccount –name my-service-account –namespace default –cluster my-cluster –attach-role-arn arn:aws:iam::account-id:role/MySecretAccessRole –approve
This service account will have the necessary permissions to retrieve secrets from AWS Secrets Manager.
Defining Secret Provider Classes: Mapping Secrets
To map the AWS secret to a Kubernetes volume, define a SecretProviderClass:
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
name: aws-secrets
spec:
provider: aws
parameters:
objects: |
– objectName: “MySecret”
objectType: “secretsmanager”
This YAML configuration tells Kubernetes how to retrieve the secret from AWS Secrets Manager and inject it into a pod.
Deploying Secure Nginx Container with Secrets
Finally, deploy an Nginx container that uses the secret:
apiVersion: v1
kind: Pod
metadata:
name: nginx-secrets
spec:
serviceAccountName: my-service-account
containers:
– name: nginx
image: nginx
volumeMounts:
– name: secrets-store
mountPath: “/mnt/secrets-store”
readOnly: true
volumes:
– name: secrets-store
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: “aws-secrets”
This configuration mounts the secrets retrieved from AWS Secrets Manager into the Nginx container.
Advanced Secret Management with External Secret Operator (ESO)
Consider using the External Secrets Operator (ESO) for more advanced secret management. ESO provides additional features such as syncing secrets across namespaces and automatic secret rotation. It integrates with AWS Secrets Manager and enhances your ability to manage secrets efficiently in complex Kubernetes environments.
Wrapping Up and Embracing a Secure Kubernetes Future
By integrating AWS Secrets Manager with Kubernetes, you ensure that your secrets are stored securely and accessed only by authorized services. This setup enhances security and simplifies secret management across your Kubernetes clusters. As your infrastructure grows, consider leveraging additional tools like the External Secrets Operator to maintain a secure and scalable environment.
References
Use AWS Secrets Manager secrets in Amazon Elastic Kubernetes Service