Securing Secrets in Kubernetes with External Secrets Operator

Introduction :-

In Kubernetes, secrets are used to store sensitive data such as passwords, API keys, and certificates. However, storing secrets directly in Kubernetes resources can lead to security risks. In this blog post, we'll explore how to secure secrets in Kubernetes using External Secrets Operator (ESO).

What is External Secrets Operator (ESO)?

External Secrets Operator (ESO) is a Kubernetes operator that enables you to store sensitive data outside of your Kubernetes cluster. ESO integrates with external secrets stores such as AWS Secrets Manager, Google Cloud Secret Manager, and HashiCorp Vault

Benefits of using ESO

• Improved security: Secrets are stored outside of Kubernetes, reducing the attack surface.

• Simplified secret management: ESO manages secrets for you, eliminating the need for manual updates.

• Centralized secret storage: Store all your secrets in one place, making it easier to manage and rotate them.

• Compliance with security regulations: ESO helps you meet security and compliance requirements.

DEMO SETUP:-

For now we are using gcp secret manager to storage and access our secrets

Step1: create a secret in google cloud

git clone https://github.com/Gkemhcs/linkedin-topics.git
cd linkedin-topics/external-secrets
gcloud auth login 
echo "enter your project id"
read PROJECT_ID
gcloud config set project  $PROJECT_ID
gcloud services enable secretmanager.googleapis.com
gcloud secrets create FRONTEND_SECRET --data-file secret.json

Step2: Create a demo gke cluster

gcloud container clusters create demo-eso --zone asia-south2-a \
--num-nodes  1 \
--machine-type e2-standard-4 \
--workload-pool $PROJECT_ID.svc.id.goog

Step3: Install external secrets operator in our cluster

helm repo add external-secrets https://charts.external-secrets.io

helm install external-secrets \
   external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \

Step4: Enable Workload-Identity to authenticate external-secrets to secret manager

gcloud iam service-accounts create  secret-accessor

export SERVICE_ACCOUNT_EMAIL="secret-accessor@${PROJECT_ID}.iam.gserviceaccount.com"

gcloud iam service-accounts add-iam-policy-binding $SERVICE_ACCOUNT_EMAIL  \
--member "serviceAccount:${PROJECT_ID}.svc.id.goog[frontend/gcpsm-accessor]" \
--role roles/iam.workloadIdentityUser

gcloud secrets add-iam-policy-binding FRONTEND_SECRET  \
--member "serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role roles/secretmanager.secretAccessor

sed -i "s/GCP_SERVICE_ACCOUNT/${SERVICE_ACCOUNT_EMAIL}/g" service-account.yaml

Step5: Deploy the k8s manifests

kubectl apply -f k8s-templates/namespace.yaml
kubectl apply -f k8s-templates/service-account.yaml
kubectl apply -f k8s-templates/secret-store.yaml
kubectl apply -f k8s-templates/external-secret.yaml
kubectl apply -f k8s-templates/deployment.yaml 
kubectl apply -f k8s-templates/service.yaml

Demo is now deployed successfully now browse through the loadbalancer ip address to verify the secrets access.

Keep sharing and commenting ,it motivates me to do some more interesting posts