CKA [Security] – Authentication和Authorization的讲解

在Kubenetes中Authentication是身份验证，看看是否有资格连上Cluster。而Authorization就是授权，看看是否有权限执行某某命令。

一、Authentication（认证）

认证用于确认请求者 “你是谁”。Kubernetes 支持多种认证方式，常见的有：

  1. 证书（X.509 Client Certificates）
    • 集群管理员为用户/组件颁发客户端证书，API Server 校验证书链和 CN/OU。
    • 优点：安全、无需额外服务；缺点：证书管理复杂，更新不便。
  2. 静态 Token（Static Bearer Token）
    • 在 API Server 启动参数 --token-auth-file 指定的文件中预先配置 <token>,<user>,<uid>,<group1>,…。
    • 优点：配置简单；缺点：无法动态增删，安全性较低。
  3. ServiceAccount（服务账户）
    • Pod 中挂载自动生成的 JWT Token，代表 Pod 身份与权限。
    • 典型场景：集群内部组件、应用调用 Kubernetes API。
  4. OpenID Connect（OIDC） / OIDC Providers
    • 通过外部身份提供商（Keycloak、Dex、Auth0 等）进行认证。
    • API Server 启动时设置 --oidc-issuer-url、--oidc-client-id 等参数。
    • 支持动态用户管理、细粒度组映射。
  5. Webhook Token Authenticator
    • 自定义 HTTP 服务，用于校验 Token 并返回用户信息。
    • 适合与现有内部认证系统集成。
  6. 其他方式
    • HTTP Basic Auth（不推荐，易泄露）
    • 匿名访问（默认被禁用或权限极低）

API Server 接收到请求后，依次尝试上述认证方式，直到有一种方式成功并映射出 user.info，否则返回 401 Unauthorized。

二、Authorization（授权）

授权用于判断 “你可以做什么”。Kubernetes 支持四种内建授权模式，可通过 API Server 参数 --authorization-mode= 启用一个或多个（通常启用 Node,RBAC）：

  1. Node
    • 专门针对 kubelet 与 kube-proxy 等节点组件请求。
    • 允许节点访问与自身相关的 API 资源。
  2. ABAC（Attribute-Based Access Control）
    • 通过 JSON 文件定义策略，每条策略包含用户、API 组、资源、动作等属性。
    • 例： 
{ 
  "apiVersion": "abac.authorization.k8s.io/v1", 
  "kind": "Policy",
  "spec": {
    "user": "alice",
    "namespace": "dev",
    "resource": "pods",
    "readonly": true
  }
}
  • 不够灵活，难以管理，现多被 RBAC 取代。

3. RBAC（Role-Based Access Control）

  • 最常用也最推荐的授权方式。
  • Role 和 ClusterRole 定义权限规则（verbs、resources、apiGroups 等）；RoleBinding 和 ClusterRoleBinding 将角色绑定到用户、组或 ServiceAccount。
  • 示例：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: read-pods-binding
subjects:
  - kind: User
    name: alice
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

4. Webhook Authorization

  • 在外部 HTTP 服务中执行自定义授权逻辑。
  • API Server 在收到请求时，向指定 webhook 发送 AuthorizationReview，根据返回结果准入或拒绝。
  • 适用于与企业自有权限中心集成。

5. AlwaysAllow

  • 完全不安全，任何已认证的请求都能做任意操作；无法做最小权限控制，也无法细化审计。

6. AlwaysDeny

  • 极端安全，任何请求都被阻断，适合锁定故障排查或安全紧急隔离场景。

注意：自己部署的kubenetes集群的话默认是AlwaysAllow的认证模式

以下是Authorization流程

Loading

Facebook评论

Related Posts