Tiny 译 分布式实验室
无论生活还是工作，我们经常会登录各种各样的网站，对于我来说，要记住每个网站的登录信息简直就像一场噩梦。
每次注册一个新网站，我会找“使用……登录”之类的链接，希望它能直接从Google或Facebook之类的地方获取我的注册信息。我发现SSO能提升用户体验，减少帐户数量的同时，也节省了一天中登录的次数。
作为Pusher的云工程师，我每天都会用Kubernetes。有一段时间，用我们的Kubernetes集群进行身份验证的体验和理想中的SSO（Single Sign-On：单点登录）相差甚远。从一开始使用Kubernetes，我们一直在用单个共享证书进行身份验证，但我们希望每位工程师都拥有自己的凭证。为此，我试图将Kubernetes的登录尽可能做的简单易用，就像我登录其他网站时选择“使用……登录”一样。
Kubernetes很棒的一点是它的认证和授权完全分离。身份认证（Authn）是用来识别用户是谁，授权（Authz）是用来确认是否允许执行某项操作。我们可以把两者想象成护照和签证。在边境，有人检查你的护照（Authn），确认你是谁，然后检查你的Visa（Authz），确认你是否有权进入他们的国家。
这篇文章中，我会阐述基于Kubernetes的身份验证，尤其是SSO的方法，但不会深入的介绍具体的配置。我会在另一篇文章[1]中介绍我们正在使用的身份验证流程，以及如何配置。
{#/foreach#}
静态密码
也叫基本身份验证。由于添加新用户，需要更新每个API服务器节点上的文件，然后重启每个API服务器，因此不利于扩展。我们很快就排除了这种方法。
X.509客户端证书
使用这种方法，每个开发人员都有自己的证书，在建立连接时会呈现给API服务器。API服务器通过验证证书和使用证书内的信息来识别该会话的用户。
证书认证有几个问题：
证书在签发时有一个有效期。它们在有效期内进行用户认证。（不使用OCSP）。
证书必须由一些通用证书签发机构（CA）签署。Kubernetes需要CA证书的副本来验证客户端证书。如果允许人们访问这些CA证书进行自签，他们就有权赋予自己任何组证书或身份。这会导致权限升级，所以必须设法集中签发证书。
签发证书并不容易，因为证书通常有很长的使用期限。
在浏览器内（例如为Kubernetes仪表板）进行证书认证比较困难。
虽然这个解决方案可以识别单个用户，但不是用户友好的方式，所以我决定找一个更简单的方案。
OpenID Connect（OIDC）
Kubernetes用OIDC实现SSO，但目前支持OIDC的供应商屈指可数。虽然这个方案乍看令人沮丧，但它确实可以实现SSO，不用为每个人创建帐号。最终，我们团队决定朝着这个方向继续调查。
OpenID Connect基于OAuth 2.0协议,在设计时考虑了身份认证。OIDC生成一个ID令牌。
此类ID令牌采用JSON Web令牌或JWT（发音为jot）的格式，如下所示：
该字符串由三部分组成，每个都是Base64编码的JSON。第一部分提供令牌的元数据。第二部分提供身份信息，即所谓的有效载荷。第三部分是签名，用于验证令牌是否是由可信方签发。
如果对有效载荷进行解码，它看起来就像这样：
有效载荷包含了发起OIDC登录流程的用户身份信息。它通常包含用户的名字和电子邮件，但也可能包含一些额外的信息，例如组别信息。
OIDC生成令牌的流程类似于OAuth 2.0：
用户点击网站上的登录按钮
该网站将其重定向到身份提供商
浏览器加载身份提供商的登录画面
用户用他们的用户名和密码登录
身份提供商将其重定向（包含查询字符串中的身份验证码）回原网站
浏览器用查询字符串中的认证码加载网站
网站服务器交换ID令牌。
Kubernetes本身不提供任何类型的OIDC认证登录网站，但你可以把从其他途径得到的令牌传递给它。这难免让人感到困惑，Kubernetes和身份提供商之间的信任关系又是怎么达成的呢？
就像之前提到过的，令牌的第三部分是签名。OIDC提供商生成的每个ID令牌都带有一个加密的密钥（通常是RS256，由提供商定期生成）。Kubernetes通过OIDC提供商的URL，检索到对应的公钥并验证该令牌是由OIDC提供商签发。至此，Kubernetes接受令牌并信任该令牌代表的用户。
一个问题是ID令牌一旦生成就没法撤销。ID令牌和Auth证书一样，有一个有效期。超过有效期，用户就要重新认证。令牌通常签发1小时，但一些提供商支持令牌刷新。令牌刷新（通常无限期地）可用于签发新的ID令牌，从而保证持久使用某项服务。
另一个问题是缺少支持。Kubernetes官方文档仅列出了三个提供商，如果你不使用Salesforce，Azure AD或Google之一，则无法体验没有内置的SSO服务。
Dex[3]在认证过程中充当中间人的角色。它是Kubernetes ID令牌的提供商和颁发者，但它本身并没有身份认证的功能，而是通过配置上游身份提供商的方式，来提供用户身份认证。
Dex和其他OIDC提供商一样，支持从GitHub，GitLab，SAML，LDAP和Microsoft获取用户信息。它的提供商插件大大提高了与客户现有的用户管理系统进行集成的能力。
Dex的另一个优势是能够控制ID令牌的发布，例如指定生命周期。它能强制组织进行重新认证。借助Dex，可以轻松撤消所有令牌，但无法撤销单个令牌。
Dex还为用户提供令牌刷新机制。当用户登录到Dex时，他会被授予一个ID令牌和一个刷新令牌。诸如kubectl之类的程序可以用这些刷新令牌，在ID令牌过期时重新认证用户。由于这些令牌是Dex发布的，因此可以通过撤销其刷新令牌来停止特定用户的刷新。这在笔记本电脑或手机丢失的情况下就非常有用。
此外，对于Dex这样的集中式认证系统，只需配置一次上游提供商即可。我们有一个设置使得上游的身份提供商只知道Dex。然后，Dex利用多个客户端，对使用内部网站和Kubernetes API的用户进行身份验证。
这种设置的一个好处是，任何用户想要往SSO系统里添加新服务，只需要在Dex配置一个PR。该设置还为用户提供基于上游身份提供商的一键式“撤销访问”的功能，用来撤销访问所有内部服务的权限。同样，这在出现安全漏洞或笔记本电脑丢失的情况下，非常有用。
在Pusher内部，通过使用Dex作为身份认证提供商的代理，使我们对用户身份令牌的签发和撤销，变得精准可控，而且，重要的是，用户不再需要用另一个身份来管理。
OIDC为工程师们提供友好的用户登录体验的同时，还可以通过RBAC的方式限制访问。
在下一篇文章中，我将更加详细地介绍在Pusher是如何配置特定的SSO，并深入说明用户如何生成ID令牌，以及他们在使用命令行和Web浏览器进行身份验证时的用户体验。同时，我也会详细地阐述如何在你的组织中实现SSO登录。
相关链接：
https://thenewstack.io/tag/Kubernetes-SSO-series
https://kubernetes.io/docs/admin/authentication/
https://github.com/coreos/dex