2. Kubernetes集群安全基线：架构安全要点、API Server认证与授权（RBAC基础）、etcd加密与访问控制

2.2 API Server认证与授权（RBAC基础）

API Server的安全模型分为三个阶段：认证（Authentication） → 授权（Authorization） → 准入控制（Admission Control）。本节重点讲解认证与RBAC授权。

2.2.1 认证机制

Kubernetes支持多种认证策略，生产环境建议同时启用多个认证模块：

• X.509客户端证书： 最常用，通过kubeconfig中的client-certificate和client-key进行身份验证。
• ServiceAccount令牌： Pod内应用访问API Server的标准方式，使用JWT令牌。
• OpenID Connect (OIDC)： 集成企业身份提供商（如Keycloak、Azure AD、Okta）。
• Webhook令牌认证： 将令牌验证委托给外部认证服务。
• 匿名请求： 默认启用但生产环境应关闭，或仅限健康检查等特定端点。

2.2.2 RBAC授权基础

RBAC（基于角色的访问控制）是Kubernetes推荐的授权模式。它通过四个核心API资源实现权限管理：

以下是一个标准的RBAC配置示例，创建一个只读角色并绑定到开发人员：

# 1. 创建只读Role（命名空间：development）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]          # 核心API组
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
# 2. 创建RoleBinding，将Role绑定到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: development
  name: read-pods-binding
subjects:
- kind: User
  name: "dev-user@example.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

下图展示了API Server的认证与授权流程，以及RBAC资源之间的关系：

2.3 etcd加密与访问控制

etcd存储了集群的所有配置、状态和Secret。如果etcd被攻破，整个集群的安全将不复存在。因此，etcd的加密与访问控制是Kubernetes安全基线的重中之重。

2.3.1 传输层加密（TLS）

etcd支持TLS双向认证，确保只有持有合法证书的客户端（主要是API Server）才能建立连接：

• --cert-file 和 --key-file：etcd服务端证书，用于向客户端证明身份。
• --client-cert-auth：启用客户端证书认证，etcd会验证API Server提供的客户端证书。
• --trusted-ca-file：CA根证书，用于验证客户端证书的签发者。
• --peer-cert-file 和 --peer-key-file：etcd集群节点间通信的证书。

2.3.2 静态数据加密（Encryption at Rest）

Kubernetes从1.7版本开始支持对etcd中的资源进行静态加密。通过配置EncryptionConfiguration对象，可以指定哪些资源需要加密以及使用哪种加密算法：

# encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
      - serviceaccounts
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: c2VjdXJlLWVuY3J5cHRpb24ta2V5LTE=
      - identity: {}  # 回退到明文存储（用于未加密的旧数据）

API Server启动参数中引用该配置文件：

--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

2.3.3 访问控制

除了TLS和加密，还需要从网络和操作系统层面限制对etcd的访问：

下图展示了etcd的加密与访问控制分层防御模型：

2.4 基线检查清单

完成本章学习后，请对照以下清单检查你的Kubernetes集群安全基线状态：