大家好！在上次的博文中，我们探讨了Kubernetes的“授权(Authorization)”方式，并强调了集群安全的重要性。今天，是时候深入探讨第一步——“认证(Authentication)”了！🔑
“你是谁？”🤔 Kubernetes API服务器向所有试图访问集群的用户和进程抛出这个问题。而对于这个问题的答案，即证明身份的各种“钥匙”也随之存在。
接下来，让我们一起了解解锁Kubernetes集群之门的各种认证方法！🚀
📜 1. X.509 客户端证书 (X.509 Client Certs)
“我有我自己的身份证明，请相信我！”
这是最常见且最强大的认证方式之一。它通过一个独特的数字身份证明来验证身份，就像您的居民身份证或驾驶执照一样。
Kubernetes集群拥有自己的证书颁发机构(Certificate Authority, CA)。该CA根据用户请求颁发X.509格式的客户端证书。此证书包含用户信息（例如：ID、组）。
当客户端（用户或kubectl等工具）向API服务器发送请求时，会同时出示此已颁发的客户端证书。API服务器使用其CA来验证此证书是否有效、由谁颁发等信息，从而完成身份认证。✅
优点:
- 非常强大的安全性 💪
- 易于在自动化系统中使用 ⚙️
- 一次设置后即可方便使用
缺点:
- 证书颁发和管理可能较为复杂 📝
- 证书有效期届满时需要更新 ⏳
大多数Kubernetes集群默认使用此方式，并且此证书信息存储在kubeconfig文件中，kubectl在与API服务器通信时会利用它。
📄 2. 静态令牌文件 (Static Token File)
“我将展示文件中记录的密码！”
顾名思义，这种认证方式是使用一个包含预定义用户名和令牌（类似于密码的字符串）的文件进行认证。
启动集群时，通过–token-auth-file选项告知API服务器特定文件的路径。此文件中逐行记录着每个用户（或服务）的ID、UID、组以及令牌。
<token>,<user-name>,<user-id>,<group1>,<group2>...当用户向API服务器发送请求时，会在HTTP头部中以Authorization: Bearer
优点:
- 设置简单，易于实现 👶
- 适用于小型集群或测试环境
缺点:
- 可能存在安全漏洞（令牌以明文形式存储在文件中的风险）⚠️
- 难以更改或管理令牌 😵💫
- 在大规模环境中效率低下
💡 注意: 如今，这被认为是一种不常用的遗留(legacy)方式。
📨 3. 请求中包含Bearer令牌 (Putting a Bearer Token in a Request)
“我持有此令牌，请承认我是‘持有者’！”
这与其说是一种特定的认证方式，不如说是向API服务器传递令牌的通用方法。“Bearer”一词蕴含着“持有此令牌的人即是该用户”的含义。🤝
前面提到的“静态令牌文件”以及后面将要解释的“引导令牌”、“服务账户令牌”、“OpenID Connect令牌”和“Webhook令牌”等各种类型的令牌，都是以“Bearer令牌”的形式包含在HTTP请求头中进行传输的。
请求示例:
GET /api/v1/pods
Authorization: Bearer <여기_에_인증_토큰_입력>API服务器从Authorization头部中提取令牌，并通过配置的多个认证模块（如静态令牌文件、OIDC等）之一来验证令牌的有效性。
🚀 4. 引导令牌 (Bootstrap Tokens)
“新加入集群的节点，请使用这个一次性密码先进入并完成基本设置！”
这些令牌是在首次构建Kubernetes集群或将新节点加入集群时临时使用的。🏗️
新节点(kubelet)要加入集群，需要与API服务器通信。在此过程中，在应用Node Authorization等授权方式之前，需要一种认证方法。引导令牌正是在这个初始设置(bootstrap)阶段，帮助kubelet临时向API服务器证明其身份，并获取所需的X.509证书。
特点:
- 有效期短 ⏰（通常24小时）
- 一次性或有限用途使用
- 主要用于kubeadm等集群构建工具
一旦节点成功加入集群，引导令牌将不再使用或过期。为了安全起见，它们被授予最小权限，并且通常以Secret的形式存储在kube-system命名空间中。
🤖 5. 服务账户令牌 (Service Account Tokens)
“我是‘数据库连接’服务。请允许我使用此令牌访问数据库！”
顾名思义，这是非人类的“服务”或“Pod”与API服务器通信时使用的认证令牌。⚙️
在Kubernetes集群中运行的应用程序(Pod)经常需要访问集群API来查询信息或创建、修改、删除资源。例如，监控Pod检查集群状态，或者部署自动化Pod部署新服务。
此时，每个Pod通常会关联一个特定的服务账户(Service Account)。并且，该服务账户会自动生成一个服务账户令牌，允许该Pod向API服务器进行认证，并以Secret的形式挂载到Pod内部。
Pod内的应用程序可以使用此令牌向API服务器发送请求。
优点:
- 集群内部工作负载(Pod)可安全访问API 👍
- 可与RBAC联动实现精细的权限控制（将RoleBinding应用于服务账户）
- 令牌管理在Kubernetes内部进行，方便快捷
🌐 6. OpenID Connect 令牌 (OpenID Connect Tokens)
“我是通过Google/Azure/Salesforce认证的用户！你可以相信我！”
这是一种通过当今网络服务中常用的外部身份提供商(Identity Provider, IdP)来认证用户的方式。🆔
您可能每天都在使用这种方式。例如，您在注册某个网站时可能点击过“使用Google账号登录”或“使用Naver账号登录”之类的按钮。OpenID Connect (OIDC)正是这种方式的标准协议。
Kubernetes API服务器可以与Azure Active Directory、Google、Salesforce等外部OIDC提供商集成，执行用户认证。
工作方式:
- 用户尝试使用kubectl等工具访问Kubernetes API。
- API服务器将用户重定向到OIDC IdP进行登录。
- 用户在IdP完成登录过程。
- IdP在登录成功后向用户颁发ID令牌(JWT)，并将其重定向回Kubernetes API服务器。
- API服务器接收并验证此ID令牌，从令牌中提取信息（用户ID、组等），完成认证。✅
优点:
- 可与现有集中式IdP（如公司SSO系统）集成，方便认证 💼
- 用户账户管理集中在一处，效率高
- 安全性高（令牌有效性验证和过期处理）
🪝 7. Webhook 令牌 (Webhook Token)
“我去问问外部系统这个令牌是否有效！”
这种方式不是由Kubernetes API服务器自身判断令牌的有效性，而是将判断权委托给外部的Webhook服务。📞
当API服务器收到包含特定令牌的请求时，它会将包含该令牌的请求发送到预先配置的外部Webhook认证服务的URL。外部服务通过其自身的逻辑和后端系统（例如：LDAP、公司内部认证数据库）验证此令牌是否有效，然后将认证结果告知API服务器。
优点:
- 可应用Kubernetes不支持的复杂或自定义认证逻辑 🧩
- 可直接利用现有的复杂认证基础设施
- 灵活性非常高
缺点:
- 需要实现和管理外部Webhook服务 🛠️
- 网络延迟或外部服务故障可能影响认证
✨ 总结
今天，我们探讨了进入Kubernetes集群的各种“认证(Authentication)”方法。
- X.509 客户端证书: 强大的数字身份证明方式
- 静态令牌文件: 简单但安全性较弱的遗留方式
- Bearer 令牌: 传递令牌的通用格式
- 引导令牌: 在集群初始配置时临时使用
- 服务账户令牌: Pod（应用程序）与API服务器通信时使用
- OpenID Connect 令牌: 通过外部IdP进行集中式认证
- Webhook 令牌: 将认证决策委托给外部服务的灵活方式
因此，Kubernetes提供了多种认证机制，帮助您根据集群环境和安全需求选择最佳方法。无论选择哪种方式，请务必记住，最重要的是遵守“最小权限原则”，并务必废弃未使用的令牌！🔒
在下一篇博文中，我们将更详细地探讨“授权(Authorization)”，它决定了“已认证用户可以做什么”。😉
标签: Kubernetes, 认证, Authentication, 安全, X509, 令牌, BearerToken, BootstrapToken, ServiceAccount, OpenIDConnect, OIDC, Webhook, K8s, DevOps
发表回复