编辑“︁Kubernetes认证”︁（章节）

= Kubernetes认证 =

'''Kubernetes认证'''（Kubernetes Authentication）是Kubernetes安全机制的核心组成部分，用于验证用户或服务账户的身份，确保只有经过授权的实体才能访问集群资源。认证过程发生在API服务器（API Server）处理请求之前，是Kubernetes访问控制的第一道防线。

== 认证机制概述 ==

Kubernetes支持多种认证方式，包括：
* '''客户端证书认证'''（X.509证书）
* '''Bearer Token认证'''（静态令牌、服务账户令牌等）
* '''OpenID Connect（OIDC）认证'''
* '''Webhook Token认证'''
* '''认证代理'''（如通过HTTP头传递用户信息）

这些机制可以单独或组合使用，具体取决于集群的配置需求。

=== 认证流程 ===
<mermaid>
sequenceDiagram
    participant Client
    participant API Server
    Client->>API Server: 发送请求（携带认证凭据）
    API Server->>API Server: 验证凭据
    alt 认证成功
        API Server-->>Client: 允许访问（进入授权阶段）
    else 认证失败
        API Server-->>Client: 返回401 Unauthorized
    end
</mermaid>

== 主要认证方式详解 ==

=== 1. 客户端证书认证 ===
通过X.509证书验证客户端身份，是最常见的生产环境认证方式。

==== 生成证书示例 ====
<syntaxhighlight lang="bash">
# 生成私钥
openssl genrsa -out user.key 2048

# 生成证书签名请求（CSR）
openssl req -new -key user.key -out user.csr -subj "/CN=alice/O=developers"

# 使用集群CA签发证书
openssl x509 -req -in user.csr -CA /path/to/ca.crt -CAkey /path/to/ca.key -CAcreateserial -out user.crt -days 365
</syntaxhighlight>

==== 配置kubeconfig ====
<syntaxhighlight lang="yaml">
apiVersion: v1
kind: Config
users:
- name: alice
  user:
    client-certificate: /path/to/user.crt
    client-key: /path/to/user.key
</syntaxhighlight>

=== 2. Bearer Token认证 ===
适用于服务账户和静态令牌认证。

==== 服务账户令牌示例 ====
Kubernetes自动为每个命名空间创建默认服务账户并生成关联的令牌：
<syntaxhighlight lang="bash">
# 查看服务账户令牌
kubectl get secret -n default
kubectl describe secret default-token-xxxxx -n default
</syntaxhighlight>

输出示例：
<pre>
Name:         default-token-xxxxx
Type:  kubernetes.io/service-account-token
Data
====
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6...
ca.crt:     1066 bytes
namespace:  7 bytes
</pre>

=== 3. OpenID Connect认证 ===
集成企业身份提供商（如Azure AD、Google等）的标准协议。

==== 配置示例 ====
API服务器启动参数：
<syntaxhighlight lang="bash">
--oidc-issuer-url=https://accounts.google.com
--oidc-client-id=your-client-id
--oidc-username-claim=email
--oidc-groups-claim=groups
</syntaxhighlight>

== 实际应用案例 ==

=== 案例1：开发团队访问控制 ===
某公司使用客户端证书认证为不同团队分配访问权限：
* 为开发团队生成证书，CN=dev-team, O=developers
* 在RBAC配置中绑定角色到组名"developers"

=== 案例2：CI/CD流水线认证 ===
使用服务账户为Jenkins配置集群访问：
<syntaxhighlight lang="yaml">
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-ci
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: jenkins-deploy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deploy-role
subjects:
- kind: ServiceAccount
  name: jenkins-ci
  namespace: default
</syntaxhighlight>

== 认证失败排查 ==

常见错误及解决方案：
{| class="wikitable"
|-
! 错误现象 !! 可能原因 !! 解决方案
|-
| 401 Unauthorized || 无效/过期的令牌或证书 || 检查令牌有效期或重新生成证书
|-
| Certificate signed by unknown authority || 未正确配置CA证书 || 确保kubeconfig包含正确的CA证书
|-
| User "system:anonymous" cannot... || 未提供认证凭据 || 检查kubectl配置或请求头
|}

== 数学原理 ==

在证书认证中，Kubernetes使用非对称加密验证签名。验证过程可表示为：

<math>
Verify_{CA}(Sig_{CA}(User_{pub}), User_{cert}) \rightarrow \text{true/false}
</math>

其中：
* <math>Sig_{CA}</math> 表示CA的签名函数
* <math>Verify_{CA}</math> 表示使用CA公钥的验证函数

== 最佳实践 ==

1. 生产环境推荐使用证书认证或OIDC
2. 定期轮换服务账户令牌
3. 避免使用静态令牌长期存储
4. 为不同用途创建专用服务账户
5. 通过审计日志监控认证活动

== 扩展阅读 ==

* Kubernetes官方文档 - 认证概述
* RFC 6749 - OAuth 2.0规范
* X.509证书标准

[[Category:Kubernetes安全]]
[[Category:Kubernetes核心概念]]
[[Category:系统认证]]

[[Category:集成部署]]
[[Category:Kubernetes]]