manage-kubernetes-secrets
정보
이 스킬은 GitOps 워크플로우에는 SealedSecrets를, 클라우드 통합에는 External Secrets Operator를 활용하여 프로덕션 등급의 Kubernetes 시크릿 관리를 제공합니다. TLS 인증서, API 키, 자격 증명에 대한 암호화, RBAC, 순환 전략을 처리합니다. 버전 관리된 시크릿, AWS Secrets Manager/Azure Key Vault와의 통합, 또는 평문 시크릿을 암호화 형식으로 마이그레이션이 필요할 때 사용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/manage-kubernetes-secretsClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Manage Kubernetes Secrets
Prod-grade secrets mgmt for K8s w/ encryption, rotation, integration w/ external secret stores.
Use When
- Storing sensitive config (API keys, passwords, tokens) for K8s apps
- GitOps workflows where secrets must be committed to VC
- Integrating K8s w/ AWS Secrets Mgr, Azure Key Vault, GCP Secret Mgr
- Rotating creds + certs w/o app downtime
- Enforcing least-privilege across namespaces + teams
- Migrating plaintext Secrets → encrypted / externally managed
In
- Req: K8s cluster w/ admin access
- Req: Secrets to manage (DB creds, API keys, TLS certs)
- Opt: Cloud secret mgr (AWS Secrets Mgr, Azure Key Vault, GCP Secret Mgr)
- Opt: CA for TLS cert gen
- Opt: GitOps repo for SealedSecrets
- Opt: KMS for encryption at rest
Do
See Extended Examples for complete config files.
Step 1: Enable K8s Secrets Encryption at Rest
Config encryption at rest for Secrets via KMS / local encryption.
# For AWS EKS, enable secrets encryption with KMS
cat > encryption-config.yaml <<EOF
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: $(head -c 32 /dev/urandom | base64)
- identity: {}
EOF
# For self-hosted clusters, configure API server
# Add to kube-apiserver flags:
# --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
# Verify encryption status
kubectl get secrets -A -o json | jq '.items[] | select(.metadata.name != "default-token") | .metadata.name'
# Encrypt existing secrets by reading and rewriting
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
# Verify a secret is encrypted at rest
# Check etcd directly (requires etcd access)
ETCDCTL_API=3 etcdctl get /registry/secrets/default/my-secret --print-value-only | hexdump -C
Cloud-managed K8s:
# AWS EKS - Create KMS key
aws kms create-key --description "EKS secrets encryption"
KMS_KEY_ARN=$(aws kms describe-key --key-id alias/eks-secrets --query 'KeyMetadata.Arn' --output text)
# Enable encryption on EKS cluster
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config "resources=secrets,provider={keyArn=$KMS_KEY_ARN}"
# GKE - Enable application-layer secrets encryption
gcloud container clusters update my-cluster \
--database-encryption-key projects/PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME
# AKS - Encryption enabled by default with platform-managed keys
# Optionally use customer-managed keys
az aks update \
--name my-cluster \
--resource-group my-rg \
--enable-azure-keyvault-secrets-provider
→ Secrets encrypted at rest in etcd. Hexdump shows encrypted, not plaintext. KMS integration configured for cloud-managed. Re-encryption of existing completes w/o errs.
If err: API server startup fails → verify encryption-config.yaml syntax + key format (base64 32-byte). KMS errs → check IAM perms allow kms:Decrypt + kms:Encrypt. etcd access issues → backup/restore to recover if encryption misconfigured.
Step 2: Install + Config Sealed Secrets for GitOps
Deploy Bitnami Sealed Secrets controller → encrypt secrets for Git storage.
# Install Sealed Secrets controller
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.0/controller.yaml
# Verify controller is running
kubectl get pods -n kube-system -l name=sealed-secrets-controller
# Install kubeseal CLI
wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.0/kubeseal-0.24.0-linux-amd64.tar.gz
tar xfz kubeseal-0.24.0-linux-amd64.tar.gz
sudo install -m 755 kubeseal /usr/local/bin/kubeseal
# Fetch public key for offline sealing
kubeseal --fetch-cert \
--controller-namespace=kube-system \
--controller-name=sealed-secrets-controller \
> pub-cert.pem
# Create a regular Secret (NOT applied to cluster yet)
kubectl create secret generic mysecret \
--from-literal=username=admin \
--from-literal=password='sup3rs3cr3t!' \
--dry-run=client \
-o yaml > mysecret.yaml
# Seal the secret
kubeseal --format=yaml --cert=pub-cert.pem < mysecret.yaml > mysealedsecret.yaml
# Inspect sealed secret (safe to commit to Git)
cat mysealedsecret.yaml
Sealed secret looks like:
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: mysecret
namespace: default
spec:
encryptedData:
username: AgA8V7f3q2... (encrypted data)
password: AgBkXp9n1h... (encrypted data)
template:
metadata:
name: mysecret
namespace: default
Apply + verify:
# Apply sealed secret to cluster
kubectl apply -f mysealedsecret.yaml
# Verify regular Secret was created automatically
kubectl get secret mysecret -o yaml
# Decode secret to verify values
kubectl get secret mysecret -o jsonpath='{.data.username}' | base64 -d
# Commit sealed secret to Git (safe, encrypted)
git add mysealedsecret.yaml
git commit -m "Add database credentials as sealed secret"
→ Sealed Secrets controller in kube-system. Public cert fetched. Kubeseal encrypts via public key. Sealed Secrets applied → auto create decrypted Secrets. Only controller can decrypt (has private key).
If err: Encryption errs → verify controller running + pub-cert.pem valid. Decryption fails → kubectl logs -n kube-system -l name=sealed-secrets-controller. Namespace mismatch → sealed secrets namespace-scoped by default; use --scope cluster-wide for cross-namespace. Private key lost → sealed secrets unrecoverable; backup controller key w/ kubectl get secret -n kube-system sealed-secrets-key -o yaml > sealed-secrets-backup.yaml.
Step 3: Deploy External Secrets Operator for Cloud Secret Mgrs
Integrate K8s w/ AWS Secrets Mgr, Azure Key Vault, GCP Secret Mgr.
# Install External Secrets Operator via Helm
helm repo add external-secrets https://charts.external-secrets.io
helm repo update
helm install external-secrets \
external-secrets/external-secrets \
--namespace external-secrets-system \
--create-namespace
# Verify operator is running
kubectl get pods -n external-secrets-system
# Create IAM role for AWS Secrets Manager (EKS with IRSA)
cat > trust-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.REGION.amazonaws.com/id/OIDC_ID"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.REGION.amazonaws.com/id/OIDC_ID:sub": "system:serviceaccount:default:external-secrets-sa"
}
}
}
]
}
EOF
aws iam create-role \
--role-name external-secrets-role \
--assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy \
--role-name external-secrets-role \
--policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
# Create SecretStore referencing AWS Secrets Manager
cat <<EOF | kubectl apply -f -
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: aws-secretsmanager
namespace: default
spec:
provider:
aws:
service: SecretsManager
region: us-east-1
auth:
jwt:
serviceAccountRef:
name: external-secrets-sa
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: external-secrets-sa
namespace: default
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/external-secrets-role
EOF
# Create secret in AWS Secrets Manager
aws secretsmanager create-secret \
--name myapp/database \
--secret-string '{
"username":"dbadmin",
"password":"dbpass123",
"endpoint":"db.example.com:5432",
"database":"myapp"
}'
# Create ExternalSecret to sync from AWS
cat <<EOF | kubectl apply -f -
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: myapp-database
namespace: default
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secretsmanager
kind: SecretStore
target:
name: myapp-db-secret
creationPolicy: Owner
data:
- secretKey: username
remoteRef:
key: myapp/database
property: username
- secretKey: password
remoteRef:
key: myapp/database
property: password
- secretKey: endpoint
remoteRef:
key: myapp/database
property: endpoint
EOF
# Verify ExternalSecret synced
kubectl get externalsecret myapp-database
kubectl get secret myapp-db-secret -o yaml
# Check synchronization status
kubectl describe externalsecret myapp-database
Azure Key Vault:
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: azure-keyvault
namespace: default
spec:
provider:
azurekv:
authType: ManagedIdentity
vaultUrl: "https://my-keyvault.vault.azure.net"
tenantId: "tenant-id"
→ Operator running. SecretStore configured w/ cloud provider creds. ExternalSecret auto creates K8s Secrets by pulling from cloud. Secrets refresh hourly. Changes in cloud → propagate to cluster.
If err: Auth errs → verify IAM role/SA annotations + trust policy allows assume role. Sync fails → kubectl describe externalsecret. Missing secrets in cloud → verify names + JSON property paths match. Test AWS creds w/ aws secretsmanager get-secret-value --secret-id myapp/database.
Step 4: Cert Mgmt w/ cert-manager
Automate TLS cert provisioning + renewal via cert-manager.
# Install cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
# Verify installation
kubectl get pods -n cert-manager
# ... (see EXAMPLES.md)
Ingress annotation-based cert issuance:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
# ... (see EXAMPLES.md)
→ cert-manager obtains cert from Let's Encrypt. TLS secret created w/ valid cert + private key. Cert auto-renews before expiration. Ingress uses for HTTPS termination.
If err: ACME challenge fails → verify DNS points to Ingress LB IP for http01 / Route53 IAM perms for dns01. Rate limit → use letsencrypt-staging for testing. Renewal fails → kubectl logs -n cert-manager deployment/cert-manager. Test cert w/ curl -v https://myapp.example.com.
Step 5: Secret Rotation Strategy
Automate rotation w/ version mgmt + app restarts.
# Enable automatic Pod restarts on Secret changes with Reloader
kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml
# Annotate Deployment to watch Secrets
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
# ... (see EXAMPLES.md)
Verify rotation workflow:
# Manually trigger rotation
kubectl create job --from=cronjob/secret-rotation manual-rotation-$(date +%s)
# Watch for Secret update
kubectl get secret myapp-db-secret -w
# Verify Reloader triggered Pod restart
kubectl get events --sort-by='.lastTimestamp' | grep Reloader
# Check new Pods are using updated secret
kubectl get pods -l app=myapp
kubectl exec -it <pod-name> -- env | grep DB_PASSWORD
→ Reloader watches Secrets/ConfigMaps + restarts Pods on changes. Rotation updates AWS Secrets Mgr → Operator syncs → Reloader triggers rolling restart. App picks up new creds w/o manual intervention.
If err: Reloader not triggering → verify annotation syntax + running kubectl get pods -n default -l app=reloader-reloader. External Secrets sync delays → decrease refreshInterval / manually trigger w/ kubectl annotate externalsecret myapp-database force-sync="$(date +%s)" --overwrite. App connection fails during rotation → implement graceful secret reload / connection pooling w/ retry.
Step 6: RBAC for Secrets Access Control
Restrict access via K8s RBAC w/ least-privilege.
# Create namespace for sensitive workloads
apiVersion: v1
kind: Namespace
metadata:
name: production
---
# ... (see EXAMPLES.md)
Test RBAC:
# Apply RBAC resources
kubectl apply -f rbac.yaml
# Test as application service account
kubectl auth can-i get secret myapp-db-secret --as=system:serviceaccount:production:myapp -n production
# Should return "yes"
# ... (see EXAMPLES.md)
→ SAs have read-only access to specific secrets via resourceNames. Devs can't view secrets in prod namespace. Only secret-admins can create/update/delete. RBAC denials logged in audit.
If err: Access denied → verify RoleBinding subjects match SA name+namespace. Overly permissive → remove wildcard verbs + add resourceNames restriction. Audit log gaps → enable K8s audit logging at API server. Test w/ kubectl auth can-i before deploying.
Check
- Secrets encrypted at rest in etcd (etcdctl / KMS)
- Sealed Secrets controller running + public cert fetched
- External Secrets Operator syncing from cloud mgrs
- TLS certs issued by cert-manager + auto-renewing
- Rotation automated w/ app restarts via Reloader
- RBAC enforces least-privilege
- No plaintext secrets in Git / container images
- Backup/restore procedure tested for sealed-secrets private key
- Monitoring alerts for sync failures + expiration
Traps
- Secrets in Git history: Committing plaintext then removing doesn't purge. Use git-filter-repo / BFG to rewrite, rotate compromised.
- Overly broad RBAC: Granting
get secretson all in namespace. Use resourceNames → specific secrets only. - No rotation: Secrets never rotated → increases blast radius. Automate via Operator / CronJobs.
- Missing encryption at rest: Secrets plaintext in etcd. Enable encryption provider / KMS before storing.
- App caching secrets: Reads once at startup, never reloads. SIGHUP / file watcher for secret file changes.
- External Secrets refresh slow: Default 1h → changes take up to 1h to propagate. Lower refreshInterval for critical / webhooks for immediate.
- No backup of sealed-secrets key: Controller private key lost → all sealed secrets unrecoverable. Backup w/
kubectl get secret -n kube-system sealed-secrets-key -o yaml > backup.yaml. - Cert renewal fails: cert-manager can't renew due to DNS/firewall changes. Monitor expiry w/ Prometheus metrics + alerts.
→
deploy-to-kubernetes— using secrets in Deployments + StatefulSetsenforce-policy-as-code— OPA policies for secret access validationsecurity-audit-codebase— detecting hardcoded secrets in app codeconfigure-ingress-networking— TLS cert usage in Ingressimplement-gitops-workflow— Sealed Secrets in ArgoCD/Flux pipelines
GitHub 저장소
연관 스킬
qmd
개발qmd는 BM25, 벡터 임베딩, 재순위화를 결합한 하이브리드 검색을 통해 로컬 파일을 색인화하고 검색할 수 있는 로컬 검색 및 색인화 CLI 도구입니다. 명령줄 사용과 Claude 통합을 위한 MCP(Model Context Protocol) 모드를 모두 지원합니다. 이 도구는 임베딩에 Ollama를 사용하고 색인을 로컬에 저장하여 터미널에서 직접 문서나 코드베이스를 검색하는 데 이상적입니다.
subagent-driven-development
개발이 스킬은 각 독립적인 작업마다 새로운 하위 에이전트를 배치하고 작업 사이에 코드 리뷰를 진행하여 구현 계획을 실행합니다. 이 리뷰 프로세스를 통해 품질 게이트를 유지하면서 빠른 반복 작업을 가능하게 합니다. 동일한 세션 내에서 대부분 독립적인 작업을 진행할 때 내장된 품질 검증과 함께 지속적인 진행을 보장하기 위해 사용하세요.
mcporter
개발mcporter 스킬은 개발자가 Claude에서 직접 Model Context Protocol(MCP) 서버를 관리하고 호출할 수 있도록 합니다. 이 스킬은 사용 가능한 서버를 나열하고, 인수를 사용해 해당 서버의 도구를 호출하며, 인증 및 데몬 생명주기를 처리하는 명령어를 제공합니다. 개발 워크플로우에서 MCP 서버 기능을 통합하고 테스트할 때 이 스킬을 사용하세요.
adk-deployment-specialist
개발이 스킬은 A2A 프로토콜을 사용하여 Vertex AI ADK 에이전트를 배포하고 오케스트레이션하며, AgentCard 검색, 작업 제출, 코드 실행 샌드박스 및 메모리 뱅크와 같은 지원 도구를 관리합니다. Python, Java 또는 Go 언어로 순차, 병렬 또는 루프 오케스트레이션 패턴을 갖춘 다중 에이전트 시스템 구축을 가능하게 합니다. Google Cloud에서 ADK 에이전트 배포 또는 에이전트 워크플로우 오케스트레이션을 요청받았을 때 사용하세요.
