kubernetes API 访问控制之：认证

2022-06-05 11:19:42 浏览数 (1)

文章目录
  • API访问控制
  • 认证
    • kubernetes账户
    • 静态密码认证
    • x509证书认证
    • 双向TLS认证
    • kubectl 如何认证? 获取$HOME/config
    • 令牌认证
    • 如何在Pod自动添加ServiceAccount:
    • 集成外部认证系统
    • Kubernetes 使用 OIDC Token 的认证流程

API访问控制

可以使用kubectl、客户端库方式对REST API的访问，Kubernetes的普通账户和Service帐户都可以实现授权访问API。API的请求会经过多个阶段的访问控制才会被接受处理，其中包含认证、授权以及准入控制（Admission Control）等。如下图所示：

需要注意：认证授权过程只存在HTTPS形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiserver，是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用HTTP，集群外部就使用HTTPS，这样既增加了安全性，也不至于太复杂。

认证

开启TLS时，所有的请求首先需要认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。如果认证成功，则用户的username会传入授权模块做进一步授权验证；对于认证失败的请求则返回HTTP 401。

当TLS建立时，HTTP请求会进行身份认证步骤，如图中步骤1，集群管理器将apiserver配置为运行一个或多个认证器模块。

认证模块包含客户端证书，密码、Plain Tokens、Bootstrap Tokens、JWT Tokens（used for service accounts）。

我们可以指定多个认证模块，每个认证模块都会按顺序进行，直到其中一个成功。

kubernetes账户

所有Kubernetes集群有两类用户：由Kubernetes管理的Service Accounts （服务账户）和（Users Accounts） 普通账户。

普通账户是假定被外部或独立服务管理的，由管理员分配keys，用户像使用Keystone或google账号一样，被存储在包含usernames和passwords的list的文件里。

需要注意：在Kubernetes中不能通过API调用将普通用户添加到集群中。

Kubernetes只专注于做应用编排，其他的功能则提供接口集成，除了认证和授权，我们发现网络、存储也都如此。

这样做的好处也显而易见，用户账户信息与Kubernetes集群松耦合，便于集成企业已有的身份认证系统，如AD、LADP、Keycloak等。

相比之下，Service Accounts是由Kubernetes API管理的帐户。它们被绑定到特定的命名空间，并由APIserver自动创建或通过API调用手动创建。Service Accounts与存储为Secrets的一组证书相关联，这些凭据被挂载到pod中，以便集群进程与Kubernetes API通信。

代码语言：javascript复制
普通帐户是针对（人）用户的，服务账户针对Pod进程。
普通帐户是全局性。在集群所有namespaces中，名称具有惟一性。
通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户。
普通帐户和服务账户的审核注意事项不同。
对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义。

静态密码认证

静态密码是最简单的认证方式，只需要在api-server启动时指定使用的密码本路径即可，通过配置-Basic-authfile=file选项实现，Basic认证凭证一直有效，并且如果没有重新启动API Server，密码将无法更改。

Basic Authentication文件csv也是格式文件，且必须包含：password, user, uid。在Kubernetes 1.6 版本中，可以指定一个可选的第四列，使用逗号来分隔group名，如果有多个组，必须使用双引号（“）。参考以下示例：

代码语言：javascript复制
password,user,uid,"group1,group2,group3"

当从http客户端使用Basic Authentication时，API Server需要在请求头加入Basic BASE64ENCODED(USER:PASSWORD)。

通过静态密码的唯一优势是简单，其缺点也是非常明显:

代码语言：javascript复制
静态密码是明文，非常不安全，还有可能被暴力破解。
非常不灵活，增加或者删除用户，必须手动修改静态密码文件并重启所有的api-server服务。

这种方式在实际场景中很少被使用，不建议生产环境使用。

x509证书认证

对称加密和非对称加密

  1. 对称加密

对称加密指的就是加密和解密使用同一个秘钥，所以叫做对称加密。对称加密只有一个秘钥，作为私钥。

常见的对称加密算法：DES，AES，3DES等等。

  1. 非对称加密

非对称加密指的是：加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。

常见的非对称加密算法：RSA，ECC

  1. 区别

对称加密算法相比非对称加密算法来说，加解密的效率要高得多。但是缺陷在于对于秘钥的管理上，以及在非安全信道中通讯时，密钥交换的安全性不能保障。所以在实际的网络环境中，会将两者混合使用.

双向TLS认证

代码语言：javascript复制
① 浏览器发送一个连接请求给安全服务器。
② 服务器将自己的证书，以及同证书相关的信息发送给客户浏览器。
③ 客户浏览器检查服务器送过来的证书是否是由自己信赖的CA中心（如沃通CA）所签发的。如果是，就继续执行协议;如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续。
④ 接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。
⑤ 服务器要求客户发送客户自己的证书。收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接;如果通过验证，服务器获得用户的公钥。
⑥ 客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。
⑦ 服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器。
⑧ 浏览器针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。
⑨ 服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥。
⑩ 服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的。

双向认证则是需要服务端与客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对于要高一些。SSL单向认证只要求站点部署了ssl证书就行，任何用户都可以去访问(IP被限制除外等)，只是服务端提供了身份认证。

使用API Server启动时配置–client-ca-file = SOMEFILE选项来启用客户端证书认证。引用的文件必须包含，提交给API Server的客户端证书的证书颁发机构。如果客户端提交的证书通过，通用名称（common name）将被用作请求的用户名。

x509认证是默认开启的认证方式，api-server启动时会指定ca证书以及ca私钥，只要是通过ca签发的客户端x509证书，则可认为是可信的客户端。

kubectl 如何认证? 获取$HOME/config

在kubectl config中会有两个证书，分别为certificate-authority证书和client-certificate证书。client-certificate用于客户端认证，这显而易见。

在使用client-certificate客户端证书认证时，CN(commom Name)对应Kubernetes的User，O(organization)对应Kubernetes的Group。

签发客户端证书有两种方式，一种是基于CA根证书签发证书，另一个种是发起CSR(Certificate Signing Requests)请求。

使用x509证书相对静态密码来说显然会更安全，只要证书不泄露，可以认为是无懈可击的。但是虽然颁发证书容易，目前却没有很好的方案注销证书。想想如果某个管理员离职，该如何回收他的权限和证书。有人说，证书轮转不就解决了吗？但这也意味着需要重新颁发其他所有证书，非常麻烦。

所以使用x509证书认证适用于Kubernetes内部组件之间认证，普通用户认证并不推荐通过证书的形式进行认证。

令牌认证

通过一个不记名令牌 (Bear Token) 来识别用户是一种相对安全又被各种客户端广泛支持的认证策略。不记名令牌，代表着对某种资源，以某种身份访问的权利，无论是谁，任何获取该令牌的访问者，都被认为具有了相应的身份和访问权限。配合成熟的令牌授予机构，不记名令牌非常适于在生产环境中严肃使用。身份令牌（ID Token）就是一种形式的不记名令牌，它本身记录着一个权威认证机构对用户身份的认证声明，同时还可以包含对这个用户授予了哪些权限的声明，像极了古代官员佩戴的腰牌。Kubernetes 接受和识别的正是这种 ID Token。

1）静态令牌认证

静态token认证和静态密码原理几乎完全一样，唯一不同的是静态token通过token-auth-file指定token文件，认证时头部格式为Authorization: Bearer

{Token}，而静态密码通过basic-auth-file指定密码文件，认证头部为Basic base64encode(

{username}

kubernetes https api json bootstrap

0 人点赞