Assess the security posture of Kubernetes etcd clusters by evaluating encryption at rest, TLS configuration, access controls, backup encryption, and network isolation.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionperforming-kubernetes-etcd-security-assessmentExecute the skills CLI command in your project's root directory to begin installation:
Fetches performing-kubernetes-etcd-security-assessment from mukul975/Anthropic-Cybersecurity-Skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate performing-kubernetes-etcd-security-assessment. Access via /performing-kubernetes-etcd-security-assessment in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
8.6K
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
8.6K
stars
| name | performing-kubernetes-etcd-security-assessment |
| description | Assess the security posture of Kubernetes etcd clusters by evaluating encryption at rest, TLS configuration, access controls, backup encryption, and network isolation. |
| domain | cybersecurity |
| subdomain | container-security |
| tags | - kubernetes - etcd - encryption - tls - security-assessment - backup - secrets - control-plane |
| version | '1.0' |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | - PR.PS-01 - PR.IR-01 - ID.AM-08 - DE.CM-01 |
etcd is the distributed key-value store that serves as Kubernetes' backing store for all cluster data, including Secrets, RBAC policies, ConfigMaps, and workload configurations. Without proper hardening, etcd exposes all cluster secrets in plaintext, making it the highest-value target for attackers who gain control plane access. A comprehensive security assessment covers encryption at rest, TLS for transport, access control, backup security, and network isolation.
Verify that Kubernetes encrypts Secret data stored in etcd:
# Check if EncryptionConfiguration is configured on API server
ps aux | grep kube-apiserver | grep encryption-provider-config
# View the encryption configuration
cat /etc/kubernetes/enc/encryption-config.yaml
Expected secure configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
- configmaps
providers:
- aescbc:
keys:
- name: key1
secret: <base64-encoded-32-byte-key>
- identity: {} # Fallback for reading unencrypted data
Verify secrets are actually encrypted in etcd:
# Read a secret directly from etcd
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
get /registry/secrets/default/my-secret | hexdump -C | head -20
# If encrypted, output starts with "k8s:enc:aescbc:v1:key1"
# If NOT encrypted, you'll see plaintext key-value pairs
# Verify etcd uses TLS for client connections
ETCDCTL_API=3 etcdctl endpoint health \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# Check peer TLS configuration
ps aux | grep etcd | tr ' ' '\n' | grep -E "peer-cert|peer-key|peer-trusted-ca"
# Verify certificate expiration
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -noout -enddate
openssl x509 -in /etc/kubernetes/pki/etcd/peer.crt -noout -enddate
Expected flags:
| Flag | Required Value | Purpose |
|---|---|---|
--cert-file | Path to server cert | Client-to-server TLS |
--key-file | Path to server key | Client-to-server TLS |
--trusted-ca-file | Path to CA cert | Client certificate validation |
--peer-cert-file | Path to peer cert | Peer-to-peer TLS |
--peer-key-file | Path to peer key | Peer-to-peer TLS |
--peer-trusted-ca-file | Path to peer CA | Peer certificate validation |
--client-cert-auth | true | Require client certificates |
--peer-client-cert-auth | true | Require peer certificates |
# Verify etcd is not exposed on all interfaces
ps aux | grep etcd | tr ' ' '\n' | grep listen-client-urls
# Should be: https://127.0.0.1:2379 (not 0.0.0.0)
# Check who can access etcd certificates
ls -la /etc/kubernetes/pki/etcd/
# Should be readable only by root/etcd user
# Verify API server is the only etcd client
ss -tlnp | grep 2379
# Only kube-apiserver should have connections
# Create an encrypted etcd backup
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# Encrypt the backup file
gpg --symmetric --cipher-algo AES256 /backup/etcd-snapshot.db
# Verify backup integrity
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot.db --write-out=table
# Verify etcd ports are firewalled
iptables -L -n | grep -E "2379|2380"
# Check if etcd is accessible from worker nodes (should NOT be)
# Run from a worker node:
curl -k https://<control-plane-ip>:2379/health
# Should be rejected/timeout
| CIS Control | Check | Expected Result |
|---|---|---|
| 2.1 | etcd cert-file set | TLS certificate configured |
| 2.2 | etcd client-cert-auth | Client certificate authentication enabled |
| 2.3 | etcd auto-tls disabled | auto-tls=false |
| 2.4 | etcd peer cert-file set | Peer TLS configured |
| 2.5 | etcd peer client-cert-auth | Peer authentication enabled |
| 2.6 | etcd peer auto-tls disabled | peer-auto-tls=false |
| 2.7 | etcd unique CA | Separate CA for etcd (not shared with cluster) |
# 1. Generate new encryption key
NEW_KEY=$(head -c 32 /dev/urandom | base64)
# 2. Update EncryptionConfiguration with new key first
cat > /etc/kubernetes/enc/encryption-config.yaml <<EOF
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key2
secret: ${NEW_KEY}
- name: key1
secret: <old-key>
- identity: {}
EOF
# 3. Restart API server to pick up new config
# 4. Re-encrypt all secrets with new key
kubectl get secrets --all-namespaces -o json | \
kubectl replace -f -
# 5. Remove old key from EncryptionConfiguration
# 6. Restart API server again
Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
performing-kubernetes-etcd-security-assessment reduced setup friction for our internal harness; good balance of opinion and flexibility.
performing-kubernetes-etcd-security-assessment fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
Registry listing for performing-kubernetes-etcd-security-assessment matched our evaluation — installs cleanly and behaves as described in the markdown.
performing-kubernetes-etcd-security-assessment has been reliable in day-to-day use. Documentation quality is above average for community skills.
Solid pick for teams standardizing on skills: performing-kubernetes-etcd-security-assessment is focused, and the summary matches what you get after install.
We added performing-kubernetes-etcd-security-assessment from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
I recommend performing-kubernetes-etcd-security-assessment for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
Keeps context tight: performing-kubernetes-etcd-security-assessment is the kind of skill you can hand to a new teammate without a long onboarding doc.
performing-kubernetes-etcd-security-assessment reduced setup friction for our internal harness; good balance of opinion and flexibility.
I recommend performing-kubernetes-etcd-security-assessment for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
showing 1-10 of 38