本文目录导读：
Kubernetes的安全配置是一个多层次、纵深防御的体系，涵盖平台、集群、工作负载和代码等多个层面，以下是Kubernetes核心且必须关注的安全配置项，按重要性和领域分类：
认证与授权（谁是“谁”？他能做什么？）
这是K8s安全的第一道防线。
-
认证（Authentication）：
- 禁用匿名访问：确保
--anonymous-auth=false（除非特定监控需求）。 - X.509客户端证书：为kubelet、kube-controller-manager等组件使用TLS证书进行双向认证。
- Service Account令牌：为Pod自动挂载服务账户令牌，但应遵循最小权限原则（
automountServiceAccountToken: false对无需API访问的Pod）。 - OIDC/Webhook：集成企业级身份提供者（如LDAP、GitHub）进行用户认证。
- 禁用匿名访问：确保
-
授权（Authorization）：
- RBAC（基于角色的访问控制）：这是最重要的配置之一。 使用
Role/ClusterRole和RoleBinding/ClusterRoleBinding精细控制用户或Service Account对资源的操作权限（“动词”如get、list、create、delete）。- 最小权限原则：避免使用
cluster-admin集群管理员角色，仅为必要组件（如ingress-controller）授予最小所需权限。
- 最小权限原则：避免使用
- ABAC（基于属性的访问控制）：不如RBAC灵活，通常不推荐。
- Node Authorization：kubelet专用的授权模式，仅允许其访问自身节点上的Pod和节点对象。
- RBAC（基于角色的访问控制）：这是最重要的配置之一。 使用
-
准入控制（Admission Controllers）：
- PodSecurityPolicy（PSP）：（K8s v1.21弃用，v1.25移除） 已被 Pod Security Admission（PSA） 或 第三方策略引擎（如OPA/Gatekeeper、Kyverno）取代。
- Pod Security Admission（PSA）：内置准入控制器，通过命名空间标签（如
pod-security.kubernetes.io/enforce: restricted）强制Pod满足Privileged、Baseline、Restricted三个安全标准之一。 - ServiceAccount：控制是否允许创建新的Service Account。
- LimitRanger：限制命名空间内Pod的资源请求和限制（CPU/内存）。
- ResourceQuota：限制命名空间级别的资源总量。
- NodeRestriction：限制kubelet仅能修改自身Pod和节点对象。
- AlwaysPullImages：强制每次启动Pod时重新拉取镜像（防止使用节点上缓存的旧版本或恶意镜像）。
- ImagePolicyWebhook：与第三方镜像扫描器集成，拒绝不符合安全策略的镜像。
工作负载安全（Pod / 容器本身）
如何保护运行中的容器？
-
Pod安全上下文（Security Context，必配）：在Pod或容器级别设置。
- 运行非root用户：
runAsNonRoot: true或runAsUser: <UID>（避免以root运行）。 - 只读根文件系统：
readOnlyRootFilesystem: true（防止容器内被篡改文件）。 - 禁止特权提升：
allowPrivilegeEscalation: false（防止通过setuid等提权）。 - 删除所有能力：
capabilities.drop: ["ALL"]，按需添加特定能力（如NET_BIND_SERVICE）。 - 限制Seccomp/AppArmor：使用默认的运行时默认配置文件（如
RuntimeDefault或特定配置文件）。
- 运行非root用户：
-
镜像安全：
- 使用官方/可信基础镜像（签名验证，如Docker Content Trust或Cosign）。
- 定期漏洞扫描（集成Trivy、Clair、Snyk等）。
- 避免
latest：使用具体版本标签，实现不可变部署。 - 最小化镜像：选择Alpine或Distroless镜像，减少攻击面。
-
网络策略（NetworkPolicy）：
- 默认拒绝入站/出站流量：创建默认拒绝策略，然后按需开放特定端口和来源。
- 精细隔离命名空间和服务：例如仅允许
frontend命名空间的Pod访问backend命名空间的数据库。
集群组件安全
保护K8s控制平面和数据平面。
-
API Server（kube-apiserver）：
- 强制TLS：所有API通信使用HTTPS（
--tls-cert-file等）。 - 禁用不安全端口：
--insecure-port=0（默认已禁用新版本）。 - 审计日志：启用
--audit-log-path并配置详细的审计策略，记录敏感操作（如create,delete,exec）。 - 请求速率限制：防止DoS攻击。
- 强制TLS：所有API通信使用HTTPS（
-
Kubelet（节点组件）：
- 认证：仅允许API Server和自身节点认证。
- 授权：使用Node授权和RBAC（
--authorization-mode Webhook）。 - 禁用匿名访问：
--anonymous-auth=false。 - 只读端口关闭：
--read-only-port=0。 - 保护证书：kubelet证书不应轻易泄露。
-
Etcd（集群状态存储）：
- 加密静态数据：使用
--experimental-encryption-provider-config或静态密钥加密存储（推荐启用EncryptionConfiguration）。 - 网络隔离：仅允许API Server访问etcd。
- TLS客户端认证：双向TLS。
- 加密静态数据：使用
-
控制面网络：禁止直接暴露API Server到公网，使用内网或VPN/Bastion主机。
其他关键配置
-
密钥管理（Secrets）：
- 开启静态加密：如上所述对etcd中的Secrets加密。
- 避免Secrets直接挂载为环境变量：优先挂载为文件（卷）或使用外部密钥管理（如HashiCorp Vault、AWS Secrets Manager、External Secrets Operator）。
- 定期轮换：密钥应定期更换。
-
日志与审计：启用审计日志，并集中存储和分析（如ELK/Fluentd）。
-
资源隔离（ResourceQuota & LimitRange）：防止单一命名空间或Pod消耗所有资源，导致拒绝服务。
-
升级与补丁：定期升级Kubernetes版本和节点操作系统，应用安全补丁。
-
容器运行时：使用安全配置的容器运行时（如containerd、CRI-O），确保Seccomp、AppArmor默认开启。
-
Pod安全标准（PSS）：利用
pod-security.kubernetes.io命名空间标签强制执行安全标准（Privileged / Baseline / Restricted）。
推荐实践工具与框架
- Kubernetes Bench for Security (kube-bench)：CIS Kubernetes基准检查工具，自动检测是否满足安全配置。
- kube-hunter：发现集群中的攻击路径和漏洞。
- OPA/Gatekeeper 或 Kyverno：作为准入控制策略引擎，实现更加复杂的自定义安全策略。
- Trivy / Falco / Sysdig：容器镜像扫描、运行时安全（异常行为检测）。
- KubeArmor：基于eBPF的容器安全，限制系统调用。
最需要立即完成的安全配置清单
- 启用RBAC，并最小化权限（避免
cluster-admin）。 - 启用Pod Security Admission（PSA） 或类似准入控制器，强制Pod运行在非root用户、只读文件系统、丢弃所有能力。
- 启用网络策略，默认拒绝入站出站流量。
- 启用etcd静态加密（
EncryptionConfiguration）。 - 启用审计日志。
- 启用kubelet的TLS认证，禁用匿名访问。
- 禁用
privileged特权容器（除非明确需求且经过严格评审）。 - 定期运行
kube-bench检查。
这些配置共同构建了一个纵深防御的Kubernetes安全体系,可以显著降低被攻击的风险。
