怎么理解Kubernetes认证和授权

发布时间：2021-12-17 10:35:49 作者：iii
来源：亿速云阅读：227

# 怎么理解Kubernetes认证和授权

## 引言

在云原生生态中，Kubernetes已成为容器编排的事实标准。随着企业越来越多地采用Kubernetes管理关键业务，**安全机制**尤其是认证（Authentication）和授权（Authorization）变得至关重要。本文将深入解析Kubernetes的认证与授权机制，帮助读者构建安全可靠的集群环境。

---

## 一、Kubernetes安全架构概述

Kubernetes的安全控制围绕**"谁（Who）能做什么（What）"**展开，核心流程分为三步：

1. **认证（Authentication）**：验证用户/服务的身份
2. **授权（Authorization）**：确定已认证身份的权限范围
3. **准入控制（Admission Control）**：对请求进行最终校验和修改

```mermaid
graph LR
    A[客户端请求] --> B{认证}
    B -->|成功| C[授权]
    C -->|通过| D[准入控制]
    B -->|失败| E[拒绝请求]
    C -->|拒绝| E

二、认证（Authentication）机制详解

2.1 认证的基本概念

Kubernetes不直接维护用户数据库，而是通过外部机制验证身份。认证模块会检查以下凭证类型：

X.509客户端证书
Bearer Token
身份代理（如OIDC）
HTTP Basic Auth（已弃用）

2.2 主要认证方式

1. X.509客户端证书

最常用的认证方式，通过TLS双向认证实现：

# 查看kubeconfig中的证书信息
kubectl config view --raw -o jsonpath='{.users[?(@.name == "my-user")].user.client-certificate-data}' | base64 -d | openssl x509 -text

证书需包含以下字段：

Subject:
  O: "system:masters"  # 用户组
  CN: "admin"          # 用户名

2. ServiceAccount Token

每个Namespace会自动创建default ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
automountServiceAccountToken: false  # 安全最佳实践

生成的JWT Token保存在Secrets中：

kubectl get secret my-sa-token-xyz -o jsonpath='{.data.token}' | base64 -d

3. OpenID Connect (OIDC)

适用于企业SSO集成，配置示例：

apiVersion: v1
kind: Config
users:
- name: oidc-user
  user:
    auth-provider:
      name: oidc
      config:
        client-id: kubernetes
        client-secret: secret
        id-token: eyJhbGciOiJSUzI1Ni...
        refresh-token: qwertyuiop
        idp-issuer-url: https://keycloak.example.com/auth/realms/master

2.3 认证流程分析

当请求到达API Server时： 1. 检查TLS证书有效性 2. 验证Bearer Token签名 3. 调用Webhook服务（如配置） 4. 最终构建用户身份对象：

   type UserInfo struct {
       Username string
       UID string
       Groups []string
       Extra map[string][]string
   }

三、授权（Authorization）机制解析

3.1 授权工作流程

通过认证后，请求会进入授权阶段。Kubernetes按顺序检查以下授权模块：

Node（节点授权）
ABAC（基于属性的访问控制）
RBAC（基于角色的访问控制，最常用）
Webhook

graph TD
    A[请求] --> B[Node授权]
    B -->|拒绝| C[结束]
    B -->|通过| D[RBAC检查]
    D -->|通过| E[Webhook]

3.2 RBAC深度解析

核心概念

Role：Namespace级别的权限集合
ClusterRole：集群级别的权限集合
RoleBinding：将Role绑定到主体
ClusterRoleBinding：将ClusterRole绑定到主体

典型示例

创建只读角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: reader
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]

绑定用户组：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-only-binding
subjects:
- kind: Group
  name: "dev-team"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: reader
  apiGroup: rbac.authorization.k8s.io

权限提升防护

Kubernetes内置了防止权限提升的机制：

kubectl auth can-i create deployments --as=system:serviceaccount:default:low-priv-sa

3.3 其他授权模式

ABAC示例

需修改API Server启动参数：

--authorization-mode=ABAC \
--authorization-policy-file=/etc/kubernetes/abac-policies.json

策略文件内容：

{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "admin",
    "namespace": "*",
    "resource": "*",
    "apiGroup": "*"
  }
}

Webhook集成

apiVersion: v1
kind: Config
clusters:
- name: authz-webhook
  cluster:
    server: https://authz.example.com/
contexts:
- context:
    cluster: authz-webhook
    user: api-server
  name: webhook
current-context: webhook

四、最佳实践与安全建议

4.1 认证层加固

禁用Anonymous请求：
```
--anonymous-auth=false
```
定期轮换ServiceAccount Token
使用cert-manager自动管理证书

4.2 授权策略优化

遵循最小权限原则

利用kubectl audit检查权限：


kubectl get roles --all-namespaces -o json | jq '.items[] | select(.rules[]?.verbs[]? | contains("*"))'

启用PodSecurityPolicy（已废弃）或替代方案

4.3 审计日志配置

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

五、常见问题排查

5.1 认证失败

错误现象：

Unauthorized (401)

检查步骤： 1. 确认kubeconfig当前上下文 2. 检查证书有效期：

   openssl x509 -in /path/to/cert.crt -noout -dates

5.2 授权拒绝