在云原生架构中，Kubernetes 已成为容器编排的事实标准。但很多团队在部署完集群后，对 API Server 的认证授权机制理解不深，导致权限配置混乱甚至安全隐患。

洹拓科技在为多家企业做云原生改造时，发现一个普遍现象：大家都在用 RBAC，但真正理解”为什么这么配”的人不多。今天我们就从 API Server 的认证流程讲起，把这套机制彻底拆开。

API Server 请求的三道关卡

当一个 kubectl 命令或 API 调用到达 API Server 时，会依次经过三个阶段：

认证（Authentication）：你是谁？

API Server 支持多种认证方式：

  • X.509 客户端证书
  • Bearer Token（ServiceAccount Token、OIDC Token）
  • Basic Auth（已废弃，别用）
  • Webhook Token 认证

生产环境推荐用 OIDC 对接企业统一身份系统，或者用 ServiceAccount Token 给 Pod 授权。

鉴权（Authorization）：你能干什么？

通过认证后，API Server 检查你是否有权限执行这个操作。主流方案是 RBAC（基于角色的访问控制），通过 Role 和 RoleBinding 定义权限边界。

准入控制（Admission Control）：你干的事合不合规？

即使有权限，某些操作可能被准入控制器拦截。比如 PodSecurityPolicy 禁止特权容器，或者自定义 Webhook 校验资源配额。

RBAC 的四个核心字段

很多团队配 RBAC 时靠”抄作业”，但真正理解这四个字段，才能配出既安全又好维护的策略：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]           # 核心 API 组
  resources: ["pods"]       # 资源类型
  verbs: ["get", "watch", "list"]  # 允许的操作

apiGroups：资源所属的 API 组。核心资源（Pod、Service）是空字符串 ""，扩展资源（Deployment）是 "apps"。

resources：具体资源类型。可以细到 pods/log，也可以粗到 pods/*。

verbs：允许的操作。get、list、watch 是只读，create、update、delete 是读写。

namespace：Role 是命名空间级别的，ClusterRole 是集群级别的。生产环境建议最小权限原则，别动不动就给 ClusterAdmin。

审计日志：事后追溯的关键

很多团队忽略审计日志，直到出事才后悔。API Server 的审计日志可以记录谁在什么时间做了什么操作：

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]

建议对 Secret、ConfigMap 等敏感资源开启 RequestResponse 级别审计，其他资源用 Metadata 级别就够了。

洹拓科技的实践建议

在为新乡本地多家企业做云原生改造时，我们总结了三条经验：

  1. 别用 default ServiceAccount：每个应用创建独立的 ServiceAccount，配合 RBAC 精细授权。

  2. 定期审计权限：用 kubectl auth can-i --list 检查实际权限，清理过期授权。

  3. 开启审计日志：至少保留 90 天，对接 SIEM 系统做异常检测。

Kubernetes 的安全不是一蹴而就的，需要从认证、授权、审计三个维度持续加固。洹拓科技为辉县及新乡全域的企业提供云原生安全评估与加固服务，欢迎联系我们。

新乡洹拓科技有限公司
地址：河南省新乡市辉县市金城百货四楼
电话：400-829-9957
业务：软件开发 | 云服务 | AI 解决方案 | 支付设备布放

#云原生 #Kubernetes #RBAC #认证 #安全运维