身份认证与用户管理
｜
93
的新手在发现这点时都会感到惊讶。它们不是通过
Kubernetes API
直接操作
的，一般情况下是由外部的用户身份管理系统定义。
这种做法的原因在于可以支持良好的用户管理。绝大多数部署了
Kubernetes
的组织都有某种形式的用户管理。用户管理可以是企业广泛使用的活动目录
（
Active Directory
）集群，也可以是一次性的
LDAP
（
Lightweight Directory
Access Protocol
，轻量目录访问协议）服务器的形式，但无论是使用哪个系统
管理用户，管理的方式都应该在整个组织内保持统一。为了支持这一设计原则，
Kubernetes
利用现有系统的连接，在基础架构中实现统一有效的用户管理。
即便没有这类的系统，也不用担心你无法使用
Kubernetes
。这可能只是意味
着你可能需要利用不同的机制来认证用户，请参照
7.2
节的介绍。
7.2
身份认证
在撰写本书之际，
Kubernetes
支持多种利用
API
进行身份认证的方法。与所
有认证机制一样，这是所有类型的程序都需要经历的第一个门槛。我们需要
在这一步中验证：“这个用户是谁？”以及“他们的身份符合我们的期望吗？”，
在
API
流程走到这一步的时候，我们尚不关心是否应该根据用户的角色授权
该请求，或者该请求是否符合我们的标准。这一步需要解决的问题很简单，
而答案非是即否：“这是一位真正的用户吗？”
与许多设计良好的基于
REST
的
API
一样，
Kubernetes
可以采用多种策略来
验证用户身份。我们可以将这些策略划分成三大类：
•
基本认证。
• X.509
客户端证书。
•
令牌。
94
｜
第
7
章
用户最终获得凭据的方式取决于集群管理员启用了哪个身份提供程序，但其
机制必然属于上述三大类之一。这些机制在实现方式上有很大差异，接下来
我们将会介绍每种机制究竟如何为
API
服务器提供验证用户的真实性以及访
问级别的数据（通过
UserInfo
资源）。
基本身份认证
基本身份认证（
Basic Authentication
）可能是
Kubernetes
集群可以使用的
最原始的身份认证插件。基本身份认证是一种机制，
API
客户端（通常是
kubectl
）将
HTTP
头部的
Authorization
设置为包含了户名和密码的
base64
哈希。由于
base64
仅仅是一个哈希值，并且不会对传进来的身份提供任何级
别的加密，因此基本身份认证必须与
HTTPS
结合使用。
为了在
API
服务器上配置基本身份认证，管理员需要提供一个静态文件，其
中包含用户名、密码、用户
ID
以及与该用户关联的组列表。格式如下：
password,username,uid,"group1,group2,group3"
password,username,uid,"group1,group2,group3"
...
注意这些数据的格式与资源
UserInfo
的字段相匹配。
你可以通过
--basic-auth-file
命令行参数，将这个文件提供给
Kubernetes
API
服务器。鉴于目前
API
服务器不会监视此文件的变更，因此无论何时添加、
删除或更新用户，都需要重新启动
API
服务器才能生效。由于这个限制，通
常不建议在生产集群中使用基本身份认证。为了获得类似于生产配置的效果，
你可以利用外部实体（如配置管理工具等）管理这个文件，但经验表明这种
方法没有可持续性。
尽管存在这些缺点，但应该注意，在快速直接测试集群时，基本身份认证仍
不失为一种优秀的工具。在没有复杂的身份认证配置的情况下，管理员可以
通过基本身份认证快速实验访问控制等功能。
身份认证与用户管理
｜
95
X.509
客户端证书
通常，大多数
Kubernetes
安装程序采用的身份认证机制都是
X.509
客户端证
书。人们这么做的原因可能很多，但我们可以肯定部分原因是这种机制很安全、
无处不在，而且可能相对容易生成。如果你可以访问签名的
CA
，那么创建用
户也非常快。
当按照生产环境的要求安装
Kubernetes
时，我们希望不仅确保用户发出的请
求能够安全地传输，而且还应该对服务之间的通信进行加密。在这种情况下，
X.509
客户端证书方便实用。但是，既然已经有这样的需求，为什么不用它来
验证用户呢？
很多安装工具正是采用了这种方法。例如，社区支持的安装程序
kubeadm
会
创建一个自签名的根
CA
证书，然后利用该证书来签署服务组件的各种证书，
以及由
kubeadm
创建的一个管理证书。
所有用户使用同一个证书并不是
Kubernetes
中管理用户的最佳方式，但它可
以帮助你搭建并启动系统。在需要添加其他用户时，管理员可以通过该签名
机构签署其他客户端证书。
kubeadm
既能方便用户建立集群，也是构建生产级集群的工具，它具有高
度可配置性。例如，用户需要使用自己的授权认证的时候，可以通过配置
kubeadm
来签署服务和用户身份认证要求的证书。
有很多工具可以帮助管理员创建并管理客户端证书。一些比较流行的工具包
括
OpenSSL
客户端工具，以及
Cloudflare
旗下一个名叫
cfssl
的工具（地址：
https://github.com/cloudflare/cfssl
）。如果你熟悉这些工具，那么你一定知道
命令行选项有时会有点麻烦。在这里我们重点讨论一下
cfssl
，因为在我们
看来，这个工具的工作流程比较容易掌握。
假设你有一个现成的
CA
。第一步是创建证书签名请求，用于生成客户端证书。
同样，我们需要将用户的身份映射到
UserInfo
资源。我们可以通过签名请求
96
｜
第
7
章
完成这一步。将公用名（
Common Name
，即
CN
）规范映射到用户名，所有
的组织字段
O
映射到用户所属的组。
cat > joesmith-csr.json <<EOF
{
"CN": "joesmith",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"L": "Boston",
"O": "qa",
"O": "infrastructure",
"OU": "Acme Sprockets Company",
"ST": "MA"
}
]
}
在上述示例中，用户“
joesmith
”既是“
qa
”也是“
infrastructure
”的成员。
我们可以按如下方式生成证书：
cfssl gencert \
-ca=ca.pem \
-ca-key=ca-key.pem \
-config=ca-config.json \
-profile=kubernetes \
joesmith-csr.json | cfssljson -bare admin
API
服务器启用
X.509
客户端证书身份认证只需指定
--client-ca-file=
，这
个值指向磁盘上的证书文件。
尽管
cfssl
简化了创建客户端证书的任务，但这种身份认证方式仍然有点笨
拙。与基本身份认证一样，当添加、删除或更改用户（例如将用户添加到新组）
时，这种方式就会显现出一些不足。如果选择证书作为身份认证选项，则至
少管理员应该确保该流程能够通过某种方式自动执行，并且这个自动化应当
考虑每过一段时间轮换证书。
如果预期最终用户的数量非常少，或者大多数用户通过某些中介（例如持续
身份认证与用户管理
｜
97
交付工具等）与集群交互，则
X.509
客户端证书可能足以胜任。但是，如果
不是这种情况，那么可能一些基于令牌的选择会更灵活。
OpenID Connect
开放认证连接（
OpenID Connect
，即
OIDC
）是在
OAuth 2.0
的基础之上构建
的身份认证层。用户可以通过
OIDC
，独立地使用受信任的身份提供商认证身
份。如果该用户身份认证成功，则
OIDC
会通过一系列
Web
请求向用户提供
一个或多个令牌。
因为代码和令牌的交换颇为复杂，而且与
Kubernetes
的认证和授权方式并没
有太大关联性，所以我们只关心期望的状态，即用户已通过身份认证并且被
授予了
id_token
和
refresh_token
。
提供给用户的令牌采用的是
RFC 7519 JSON Web Token
（
JWT
）的格式。该
开放标准允许在多方之间表示用户声明。简单来说，我们可以通过一小部分
可供人类解析的
JSON
，共享用户名、用户
ID
及用户所在组等信息。这些令
牌使用哈希运算消息认证码（
Hash-based Message Authentication Code
，即
HMAC
）进行身份认证，并且未加密。因此，需要确保包括
JWT
在内的所有
通信都是加密的，最好使用
TLS
。
常见的令牌负荷大致如下：
{
"iss": "https://auth.example.com",
"sub": "Ch5hdXRoMHwMTYzOTgzZTdjN2EyNWQxMDViNjESBWF1N2Q2",
"aud": "dDblg7xO7dks1uG6Op976jC7TjUZDCDz",
"exp": 1517266346,
"iat": 1517179946,
"at_hash": "OjgZQ0vauibNVcXP52CtoQ",
"username": "user",
"email": "user@example.com",
"email_verified": true,
"groups": [
"qa",
"infrastructure"
]
}
Get 管理Kubernetes now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
