Token导航 LogoToken导航

Agent Skill · 开发

eks-security(埃克斯安全)

用于辅助安全审计、权限检查、凭据风险、认证流程和常见漏洞排查。它适合让 Agent 梳理敏感配置、检查依赖风险、分析鉴权逻辑或生成安全复核清单。使用时不能把工具输出直接当最终结论,涉及密钥、令牌、用户数据或生产系统时,应先确认最小权限、脱敏方式和操作边界。

eks-security 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证为 MIT,第三方扫描已通过,按安装量在开发类的 21,746 个 Skill 里排第 17,326。

总安装 420周安装 17GitHub Stars 9下载 132核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:eks-security(埃克斯安全)
来源仓库:https://github.com/adaptationio/skrillz
仓库路径:skills/eks-security
安装命令:
npx skills add https://github.com/adaptationio/skrillz --skill eks-security
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/adaptationio/skrillz --skill eks-security

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

eks-security 提供 EKS 集群安全加固指南,涵盖控制平面和工作负载防护。适用于合规审计、漏洞扫描和网络策略实施等场景。包含 Pod 安全标准、镜像扫描和运行时安全最佳实践。使用前需评估业务影响,避免在生产环境直接修改安全配置。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/eks-security

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/adaptationio/skrillz --skill eks-security;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

eks-security 怎么安装?

在终端执行 npx skills add https://github.com/adaptationio/skrillz --skill eks-security。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

eks-security 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

eks-security 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

eks-security 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

eks-security 用的人多吗?

公开数据是累计安装 420 次,近一周安装 17 次,下载 132 次,GitHub 9 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

eks-security 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
eks-security

埃克斯安全 · 本页

4209需要联网MIT通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

EKS Security

Overview

Comprehensive security hardening guide for Amazon EKS clusters following 2025 best practices. This skill covers control plane security, workload isolation, secrets management, network policies, image scanning, runtime security, and compliance frameworks.

Keywords: EKS security, cluster hardening, IRSA, Pod Security Standards, network policies, secrets management, compliance, vulnerability scanning, runtime security, incident response

Status: Production-ready (2025 best practices)

When to Use This Skill

  • Hardening new EKS clusters for production
  • Implementing security controls and policies
  • Configuring RBAC and IAM access
  • Setting up secrets management
  • Preparing for compliance audits (CIS, NIST, SOC2)
  • Responding to security incidents
  • Scanning and remediating vulnerabilities
  • Implementing zero-trust networking
  • Setting up runtime security monitoring

Security Architecture Overview

┌─────────────────────────────────────────────────────────────┐
│                     EKS Security Layers                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Layer 1: Control Plane Security                           │
│  • Private API endpoint                                     │
│  • Audit logging enabled                                    │
│  • Secrets encryption with KMS                             │
│  • IP allowlisting                                          │
│                                                             │
│  Layer 2: Authentication & Authorization                    │
│  • IAM Roles for Service Accounts (IRSA)                   │
│  • RBAC with least privilege                               │
│  • Pod Identity for workloads                              │
│  • Service account isolation                               │
│                                                             │
│  Layer 3: Workload Security                                │
│  • Pod Security Standards (restricted)                      │
│  • Security contexts                                        │
│  • Read-only root filesystems                              │
│  • Non-root users                                           │
│  • Resource limits                                          │
│                                                             │
│  Layer 4: Network Security                                  │
│  • Network Policies (VPC CNI 1.14+)                        │
│  • Security Groups for Pods                                │
│  • Private subnets for nodes                               │
│  • VPC Flow Logs                                            │
│  • mTLS with service mesh                                  │
│                                                             │
│  Layer 5: Secrets & Data Protection                        │
│  • External Secrets Operator                               │
│  • AWS Secrets Manager integration                         │
│  • Encrypted etcd                                           │
│  • Automatic rotation                                       │
│                                                             │
│  Layer 6: Image & Runtime Security                         │
│  • Amazon Inspector scanning                               │
│  • Admission controllers (OPA/Gatekeeper)                  │
│  • Runtime monitoring (Falco, GuardDuty)                   │
│  • Image signing/verification                              │
│                                                             │
│  Layer 7: Compliance & Audit                               │
│  • CloudTrail logging                                       │
│  • GuardDuty for EKS                                       │
│  • Security Hub integration                                 │
│  • CIS/NIST compliance checks                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Quick Start: Essential Security Checklist

Cluster Level (Day 0)

  • Enable private API endpoint (or public + IP allowlist)
  • Enable all control plane logging
  • Configure secrets encryption with KMS
  • Use latest Kubernetes version (within 2 versions)
  • Enable audit logging
  • Configure VPC with private subnets

Node Level (Day 0)

  • Use Amazon Linux 2023 or Bottlerocket AMI
  • Enable IMDSv2 enforcement
  • Minimal IAM permissions for node role
  • Deploy nodes in private subnets only
  • Enable SSM for remote access (disable SSH)
  • Plan for regular node rotation (21 days max)

Workload Level (Day 1)

  • Implement Pod Security Standards (restricted level)
  • Use IRSA for all AWS service access
  • No privileged containers
  • Configure security contexts (runAsNonRoot, readOnlyRootFilesystem)
  • Set resource limits and requests
  • Use dedicated service accounts per application

Network Level (Day 1)

  • Enable network policies (VPC CNI 1.14+ or Calico/Cilium)
  • Configure default deny-all policies
  • Use Security Groups for Pods for AWS resource access
  • Enable VPC Flow Logs
  • Restrict egress traffic
  • Deploy private load balancers where possible

Secrets Management (Day 1)

  • Deploy External Secrets Operator
  • Migrate secrets to AWS Secrets Manager
  • Enable automatic secret rotation
  • Remove hardcoded credentials
  • Audit secret access via CloudTrail

Image Security (Day 1-2)

  • Enable Amazon Inspector for ECR repositories
  • Configure automatic scanning on push
  • Block deployment of critical vulnerabilities
  • Implement image signing (Sigstore/Notary)
  • Use minimal base images (distroless, Chainguard)
  • ECR lifecycle policies for old images

Compliance & Monitoring (Day 2-3)

  • Enable GuardDuty for EKS
  • Configure Security Hub
  • Run kube-bench for CIS compliance
  • Deploy runtime security (Falco)
  • Set up CloudWatch alarms for security events
  • Configure SIEM integration

Security Workflow

Phase 1: Foundation (Control Plane)

  1. Review control plane endpoint configuration
  2. Enable comprehensive logging
  3. Configure KMS encryption for secrets
  4. Set up IAM authentication
  5. Implement API access controls

See: references/cluster-security.md

Phase 2: Workload Hardening

  1. Implement Pod Security Standards
  2. Configure security contexts
  3. Set up IRSA for service accounts
  4. Deploy RBAC policies
  5. Enable admission controllers

See: references/workload-security.md

Phase 3: Secrets & Data Protection

  1. Deploy External Secrets Operator
  2. Migrate secrets to AWS Secrets Manager
  3. Configure automatic rotation
  4. Set up CSI Secrets Store Driver (if needed)
  5. Audit and monitor secret access

See: references/secrets-management.md

Phase 4: Network Security

  1. Enable network policies
  2. Configure default deny rules
  3. Set up Security Groups for Pods
  4. Implement service mesh with mTLS (optional)
  5. Enable VPC Flow Logs

Phase 5: Runtime Security

  1. Deploy image scanning
  2. Configure admission controllers
  3. Set up runtime monitoring (Falco)
  4. Enable GuardDuty for EKS
  5. Configure incident response

Phase 6: Compliance & Audit

  1. Run security benchmarks
  2. Configure continuous compliance
  3. Set up security dashboards
  4. Document security controls
  5. Conduct regular security reviews

Critical Security Controls

1. IAM Roles for Service Accounts (IRSA)

Why: Provides pod-level AWS permissions without node-level credentials

Quick Implementation:

# Service Account with IRSA
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/my-app-role

Best Practices:

  • One service account per application
  • Explicit trust policies with namespace and SA name
  • Least privilege IAM policies
  • Regular audit of role usage

Details: references/cluster-security.md#irsa

2. Pod Security Standards

Why: Prevents privilege escalation and enforces security best practices

Quick Implementation:

# Restricted namespace
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Levels:

  • privileged: No restrictions (avoid in production)
  • baseline: Minimal restrictions (development)
  • restricted: Comprehensive restrictions (REQUIRED for production)

Details: references/workload-security.md#pod-security-standards

3. Network Policies

Why: Implement microsegmentation and zero-trust networking

Quick Implementation:

# Default deny all traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Capabilities:

  • Pod-to-pod traffic control
  • Namespace isolation
  • External service access control
  • Defense in depth with Security Groups for Pods

Details: references/workload-security.md#network-policies

4. External Secrets Operator

Why: Centralized secret management with automatic rotation

Quick Implementation:

# ExternalSecret resource
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets-k8s
  data:
  - secretKey: db-password
    remoteRef:
      key: prod/db/password

Benefits:

  • Automatic synchronization
  • Works with Fargate (unlike CSI driver)
  • Multiple backend support
  • Audit trail via CloudTrail

Details: references/secrets-management.md#external-secrets-operator

5. Container Image Scanning

Why: Identify and remediate vulnerabilities before deployment

Amazon Inspector 2025 Features:

  • Container image mapping (shows running containers)
  • Extended coverage (distroless, scratch, Chainguard)
  • Continuous monitoring with automatic rescans
  • Prioritization based on actively running images

Quick Setup:

# Enable enhanced scanning
aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{"repositoryFilters":[{"filter":"*","filterType":"WILDCARD"}],"scanFrequency":"CONTINUOUS_SCAN"}]'

Details: references/workload-security.md#image-scanning

6. Runtime Security Monitoring

Why: Detect and respond to threats in real-time

Tools:

  • Amazon GuardDuty for EKS: Managed threat detection
  • Falco: Open-source runtime security
  • OPA/Gatekeeper: Policy enforcement

GuardDuty for EKS Capabilities:

  • Suspicious API calls
  • Privilege escalation attempts
  • Cryptocurrency mining detection
  • Anomalous network activity
  • Container escape attempts

Details: references/workload-security.md#runtime-security

Security Patterns

Pattern 1: Zero-Trust Cluster (Maximum Security)

Configuration:

  • Private API endpoint only
  • All nodes in private subnets
  • Network policies enabled (default deny)
  • Pod Security Standards (restricted)
  • mTLS service mesh (Istio)
  • No public load balancers
  • VPN/Direct Connect for access

Use Case: Healthcare, finance, regulated industries

Pattern 2: Defense-in-Depth Production Cluster

Configuration:

  • Public + private API endpoints
  • IP allowlist on public endpoint
  • Nodes in private subnets
  • Network policies + Security Groups for Pods
  • Pod Security Standards (restricted)
  • External Secrets Operator
  • GuardDuty + Inspector enabled

Use Case: Standard production workloads

Pattern 3: Multi-Tenant Cluster

Configuration:

  • Namespace isolation with RBAC
  • ResourceQuotas per namespace
  • Network policies per namespace
  • Dedicated node groups with taints/tolerations
  • Pod Security Standards per namespace
  • Audit logging of all API calls

Use Case: Platform teams, SaaS applications

Compliance Frameworks

CIS Kubernetes Benchmark

Tool: kube-bench

# Run CIS benchmark
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml

# View results
kubectl logs -n kube-bench job/kube-bench

Key Controls:

  • Control plane security
  • Worker node configuration
  • Pod security policies
  • Network policies
  • Authentication/authorization

NIST 800-190 (Container Security)

Five Areas:

  1. Image security and integrity
  2. Registry security
  3. Orchestrator security
  4. Container runtime security
  5. Host OS security

Implementation: See detailed mapping in references/cluster-security.md#compliance

SOC2 / HIPAA / PCI-DSS

Common Requirements:

  • Encryption at rest and in transit
  • Audit logging and monitoring
  • Access controls (RBAC + IRSA)
  • Vulnerability scanning
  • Incident response procedures
  • Regular security assessments

Security Incident Response

Detection Sources

  1. GuardDuty alerts
  2. CloudWatch alarms
  3. Falco runtime alerts
  4. Audit log anomalies
  5. Network traffic analysis
  6. Container image scan results

Response Workflow

  1. Identify: Determine scope and severity
  2. Contain: Isolate affected workloads
  3. Eradicate: Remove malicious components
  4. Recover: Restore from known-good state
  5. Review: Post-incident analysis

Common Scenarios

Compromised Pod:

# Immediate isolation
kubectl label pod <pod-name> security=isolated
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-compromised-pod
spec:
  podSelector:
    matchLabels:
      security: isolated
  policyTypes:
  - Ingress
  - Egress
EOF

# Collect forensics
kubectl logs <pod-name> > pod-logs.txt
kubectl exec <pod-name> -- ps aux > processes.txt

# Delete pod
kubectl delete pod <pod-name>

Details: references/workload-security.md#incident-response

Detailed Documentation

For comprehensive security configurations and advanced topics:

- Control plane hardening - API endpoint configuration - Audit logging setup - IRSA detailed configuration - RBAC best practices - Compliance frameworks

- Pod Security Standards implementation - Security contexts configuration - Network policies patterns - Image scanning and verification - Runtime security (Falco, GuardDuty) - Admission controllers (OPA/Gatekeeper) - Incident response procedures

- External Secrets Operator setup - AWS Secrets Manager integration - CSI Secrets Store Driver - Secret rotation strategies - Encryption configuration - Audit and monitoring

Security Assessment Tools

Scanning and Assessment

  • kube-bench: CIS Kubernetes benchmark
  • kube-hunter: Active vulnerability scanning
  • Polaris: Configuration validation
  • Trivy: Vulnerability and misconfiguration scanning
  • Checkov: IaC security scanning

Runtime Security

  • Falco: Runtime threat detection
  • GuardDuty for EKS: AWS-managed threat detection
  • Sysdig: Container security platform

Policy Enforcement

  • OPA/Gatekeeper: Policy as code
  • Kyverno: Kubernetes-native policy engine
  • Pod Security Admission: Built-in PSS enforcement

Common Security Anti-Patterns to Avoid

Anti-PatternRiskSolution
Using default service accountsOverly permissiveCreate dedicated service accounts per app
Privileged containersHost access, container escapeUse specific capabilities, PSS restricted
Hardcoded secrets in manifestsCredential exposureUse External Secrets Operator
No network policiesLateral movementImplement default-deny policies
Running as rootPrivilege escalationSet runAsNonRoot: true
Public API endpoint without restrictionsUnauthorized accessUse private endpoint or IP allowlist
No image scanningVulnerability deploymentEnable Amazon Inspector
Shared node IAM rolesExcessive permissionsUse IRSA for pod-level permissions
No resource limitsResource exhaustionSet requests and limits
Missing audit logsNo forensic capabilityEnable all control plane logs

Automated Security Hardening

Terraform Module (Recommended)

module "eks_security" {
  source = "./modules/eks-security"

  cluster_name = "production-cluster"

  # Control plane
  enable_private_endpoint = true
  enable_public_endpoint  = false
  enable_audit_logging    = true
  kms_key_arn            = aws_kms_key.eks.arn

  # Workload security
  pod_security_standard = "restricted"
  enable_network_policies = true

  # Secrets
  deploy_external_secrets = true
  secrets_manager_role_arn = aws_iam_role.secrets.arn

  # Monitoring
  enable_guardduty = true
  enable_inspector = true

  # Compliance
  cis_compliance_mode = true
}

See full examples: references/cluster-security.md#terraform

Security Roadmap

Week 1: Foundation

  • Review and harden control plane
  • Configure audit logging
  • Set up IRSA for critical workloads
  • Enable Pod Security Standards

Week 2: Network & Secrets

  • Deploy network policies
  • Implement External Secrets Operator
  • Configure Security Groups for Pods
  • Enable VPC Flow Logs

Week 3: Scanning & Runtime

  • Enable Amazon Inspector
  • Deploy GuardDuty for EKS
  • Configure Falco (optional)
  • Set up admission controllers

Week 4: Compliance & Operations

  • Run CIS benchmark
  • Configure Security Hub
  • Document security controls
  • Train team on incident response
  • Schedule regular security reviews

Quick Reference Commands

Security Audit

# Check Pod Security Standards
kubectl get namespaces -o custom-columns=NAME:.metadata.name,PSS:.metadata.labels.pod-security\.kubernetes\.io/enforce

# List service accounts with IRSA
kubectl get sa -A -o jsonpath='{range .items[?(@.metadata.annotations.eks\.amazonaws\.com/role-arn)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.metadata.annotations.eks\.amazonaws\.com/role-arn}{"\n"}{end}'

# Check for privileged pods
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.containers[*].securityContext.privileged==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

# List pods running as root
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.securityContext.runAsNonRoot!=true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

# Check network policies
kubectl get networkpolicies -A

# View audit logs
aws logs tail /aws/eks/production-cluster/cluster --follow --filter-pattern '{ $.verb != "get" && $.verb != "list" && $.verb != "watch" }'

Security Monitoring

# GuardDuty findings
aws guardduty list-findings --detector-id <detector-id> --finding-criteria '{"Criterion":{"resource.resourceType":{"Eq":["EKS"]}}}'

# Inspector scan results
aws inspector2 list-findings --filter-criteria '{"ecrImageRepositoryName":[{"comparison":"EQUALS","value":"my-repo"}]}'

# CloudWatch Container Insights
aws cloudwatch get-metric-statistics \
  --namespace ContainerInsights \
  --metric-name pod_cpu_utilization \
  --dimensions Name=ClusterName,Value=production-cluster

Last Updated: November 2025 Kubernetes Version: 1.33 Security Standards: CIS Kubernetes Benchmark 1.8, NIST 800-190, AWS Well-Architected Status: Production-ready

平台分布

github-copilot

28.77%
按下载量换算38

Claude Code

25.54%
按下载量换算34

mcpjam

17.62%
按下载量换算23

moltbot

12.93%
按下载量换算17

windsurf

8.19%
按下载量换算11

zencoder

3.95%
按下载量换算5

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

继续浏览同类 Skills