Cloud & IT Cert Prep · 课时

Kubernetes 安全：RBAC、网络策略与 Pod 安全

配置 Kubernetes RBAC 角色，强制执行限制 Pod 间流量的网络策略，并应用 Pod 安全标准来限制权限提升。

Kubernetes 安全：RBAC、网络策略与 Pod 安全 是 CoddyKit 上的免费 Cloud & IT Cert Prep 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Cloud & IT Cert Prep 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Cloud & IT Cert Prep 课程共包含 4 节课。

Kubernetes 攻击面概览

Kubernetes可以大规模编排容器化工作负载，但其复杂性也造就了广泛的攻击面。必须加以保护的关键组件包括：API 服务器（中央控制平面——一旦被攻陷，攻击者就能控制整个集群）；etcd（集群状态数据库——以 base64 格式存储机密信息，必须进行静态加密）；kubelet（节点代理——未进行身份验证的 kubelet API 允许任意执行 Pod）；容器运行时（Docker/containerd）；以及连接所有 Pod 的网络结构。Security+ 考生应了解，Kubernetes 配置错误是最常见的云安全发现之一。

RBAC：Kubernetes 中基于角色的访问控制

Kubernetes RBAC（基于角色的访问控制）控制用户、服务账户和进程可以对哪些 API 资源执行哪些操作。该模型包含四种对象：Role（命名空间范围的权限）、ClusterRole（集群范围的权限）、RoleBinding（在命名空间内向主体授予 Role）和 ClusterRoleBinding（在整个集群范围内向主体授予 ClusterRole）。每条 kubectl 命令都会转换为 API 调用，并根据 RBAC 规则进行检查。如果未配置 RBAC，任何经过身份验证的用户（或服务账户）都可能拥有管理权限。

# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [''] 
  resources: ['pods']
  verbs: ['get', 'list', 'watch']

服务账户与最小权限

Kubernetes 中的每个 Pod 都以某个服务账户运行，该账户是用于 API 身份验证的身份。默认情况下，Pod 使用其命名空间中的 default 服务账户，而该账户可能拥有过于宽泛的权限。最小权限原则要求为每个应用程序创建专用服务账户，并且只授予应用程序所需的权限。此外，对于不需要 API 访问权限的 Pod，将 automountServiceAccountToken: false 设置为禁用自动挂载，可防止服务账户令牌被挂载到 Pod 文件系统中；否则，被攻陷的应用程序可能利用该令牌发起 API 调用。

# Pod spec: disable service account token auto-mount
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: myapp-sa
  automountServiceAccountToken: false
  containers:
  - name: myapp
    image: myapp:v1.0

网络策略：默认拒绝

在 Kubernetes 中，默认情况下，所有 Pod 都可以与任意命名空间中的其他 Pod 通信。被攻陷的 Pod 可以立即尝试访问数据库、内部 API 和其他微服务。Kubernetes NetworkPolicy 资源可根据标签、命名空间和端口定义限制 Pod 间流量的规则。推荐的做法是在每个命名空间中设置“默认拒绝全部”的网络策略，然后针对必需的通信路径明确添加允许规则。请注意，NetworkPolicy 需要支持该功能的 CNI 插件（Calico、Cilium、Weave）；没有兼容的 CNI 时，原生 Kubernetes 会忽略 NetworkPolicy。

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

Pod 安全标准：取代 PSP

Pod Security Standards（PSS）在 Kubernetes 1.23 中引入，并在 1.25 中稳定，用三个内置配置文件取代已弃用的 Pod Security Policy（PSP）；这些配置文件在命名空间级别强制执行：Privileged（不受限制，用于系统组件）、Baseline（阻止已知的权限提升方式，例如特权容器和主机网络访问）以及 Restricted（强化配置，要求使用非 root 用户、删除所有功能并强制根文件系统只读）。命名空间通过添加标签来强制执行策略级别，违反策略的 Pod 会在准入阶段被拒绝。

# Label namespace to enforce 'restricted' pod security
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Kubernetes 中的机密信息管理

Kubernetes Secrets 用于存储密码、令牌和 TLS 证书等敏感数据。默认情况下，Secrets 以经过 base64 编码的值存储在 etcd 中，并未加密。任何能够读取 etcd 或拥有足够 RBAC 权限的人，都可以轻易将其解码。最佳实践包括：使用存储在 KMS 中的密钥通过 AES-GCM 启用etcd 静态加密（AWS KMS、GCP KMS）；通过 Secrets Store CSI Driver 集成 HashiCorp Vault 或 AWS Secrets Manager 等外部机密管理器；以及通过 RBAC 限制 Secret 访问权限，使只有需要这些 Secret 的服务账户才能读取它们。

# Enable etcd encryption at rest (encryption configuration)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>

准入控制器：安全关卡

准入控制器是 Kubernetes API 服务器中的插件，会在身份验证和授权之后、对象持久化之前拦截 API 请求，从而验证、修改或拒绝请求。与安全相关的准入控制器包括：PodSecurity（强制执行 Pod 安全标准）、ImagePolicyWebhook（允许验证外部镜像签名）、AlwaysPullImages（强制重新拉取镜像，防止使用本地缓存的恶意镜像）以及 OPA/Gatekeeper（开放策略代理，灵活性最高，可使用 Rego 语言表达自定义策略，以强制执行任意组织安全规则）。

集群组件加固

加固 Kubernetes 控制平面组件至关重要：API 服务器应设置 --anonymous-auth=false 以禁用未经过身份验证的访问，配置 --audit-log-path 以记录所有 API 活动，并为所有连接启用 TLS。kubelet 应设置 --authorization-mode=Webhook（而不是 AlwaysAllow），并禁用匿名身份验证。etcd 应启用对等端和客户端 TLS 加密，限制网络访问（仅允许 API 服务器访问），并对静态数据进行加密。CIS Kubernetes 基准为所有组件设置提供了全面的检查清单。

# Check kubelet configuration for security issues
kubectl get --raw /api/v1/nodes/nodename/proxy/configz | jq '.kubeletconfig | {anonymousAuth: .authentication.anonymous.enabled, authorization: .authorization.mode}'

命名空间隔离与多租户

Kubernetes 命名空间可以实现资源的逻辑分离，但其本身并不是强安全边界，主要提供组织层面的隔离。要实现真正的多租户隔离（例如隔离不同客户的工作负载），还需要额外的控制措施：使用网络策略阻止跨命名空间流量；使用资源配额防止邻居噪声导致拒绝服务；为需要强隔离的租户使用独立节点池；或为每个租户使用专用集群。许多组织会使用分层命名空间或 vCluster 等商业解决方案，在单个集群内实现更强的多租户能力。

审计日志记录与运行时监控

Kubernetes 审计日志记录会记录每个 API 请求：请求者、请求来源、请求的操作以及目标资源。安全事件发生后，审计日志对于取证调查至关重要，也有助于检测异常行为，例如不寻常的角色绑定、访问机密信息，或通过 exec 命令进入生产环境中的 Pod。审计日志应流式传输到集中式 SIEM。Falco 提供容器行为的运行时监控，而云托管的 Kubernetes 服务（EKS、GKE、AKS）则与各自的日志记录平台提供原生审计日志集成。

# Check recent kubectl exec events in audit log
grep '"verb":"create".*"resource":"pods".*"subresource":"exec"' /var/log/kubernetes/audit.log | tail -20

供应链安全：镜像来源

Kubernetes 的供应链安全可确保只有受信任且经过验证的镜像才能进入生产环境。CNCF 的供应链安全建议包括：在部署前使用 Cosign 验证镜像签名（通过准入控制器强制执行）；为所有容器镜像生成并验证SBOM（软件物料清单），以跟踪组件来源；将镜像固定到摘要（myimage@sha256:abc123），而不是使用可变标签；并在部署前扫描所有第三方 Helm 图表，检查错误配置和漏洞。

# Pin image to digest for immutability
# Instead of:
image: nginx:latest
# Use:
image: nginx@sha256:a3e2a7a3d7f94e...  # immutable digest

快速检查

请检验您对本课 CompTIA Security+（SY0-701）相关概念的理解。

课程回顾

本课您学习了：Kubernetes RBAC 通过 Roles、ClusterRoles 和绑定控制 API 访问——请始终为服务账户应用最小权限原则；NetworkPolicy 默认拒绝配置可防止 Pod 和命名空间之间的横向移动；Pod 安全标准强制执行容器加固，在命名空间级别阻止特权容器、主机网络访问和以 root 身份执行。接下来我们将探讨无服务器安全和函数级攻击面。

常见问题解答

「Kubernetes 安全：RBAC、网络策略与 Pod 安全」课时是免费的吗？

是的 — 「Kubernetes 安全：RBAC、网络策略与 Pod 安全」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Cloud & IT Cert Prep 课程的其余内容，请升级到 CoddyKit PRO。 Cloud & IT Cert Prep 课程共包含 4 节课。

「Kubernetes 安全：RBAC、网络策略与 Pod 安全」这节课中我会学到什么？

配置 Kubernetes RBAC 角色，强制执行限制 Pod 间流量的网络策略，并应用 Pod 安全标准来限制权限提升。你通过在浏览器中直接运行的动手代码来练习 Cloud & IT Cert Prep，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Cloud & IT Cert Prep 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Cloud & IT Cert Prep 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「Kubernetes 安全：RBAC、网络策略与 Pod 安全」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Cloud & IT Cert Prep 课中编写并运行代码吗？

能。每节 Cloud & IT Cert Prep 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Cloud & IT Cert Prep