带你读《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.3 Kube-APIServer 介绍(二)-阿里云开发者社区

开发者社区> 人民邮电出版社> 正文
登录阅读全文

带你读《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.3 Kube-APIServer 介绍(二)

简介: 带你读《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.3 Kube-APIServer 介绍

2.3.2         认证

 

1. 认证中使用的用户

 

Kubernetes集群中有两种用户:一种是由 Kubernetes管理的 ServiceAccount;另一种是普通用户。普通用户是由集群之外的服务管理的,比如存储在Keystone中的用户、存储在文件中的用户和存储在 ldap中的用户等。 所有的 API请求中都绑定了一个ServiceAccount或普通用户,如果都未绑定,就是一个使用匿名用户的请求。

ServiceAccount与它关联的请求中的用户是什么样的呢?ServiceAccoount在Kuberentes中关联着一个 Secret,这个 Secret中包括一个 JWT格式的 Token,它会使用 Token中的 Payload中的 Sub 字段作为请求用户的名称。下面是对 Secret中的 Token解析的一个示例,请求所使用的用户名是 system:serviceaccount:default:default,见代码清单 2-60。

{

"iss":"kubernetes/serviceaccount","kubernetes.io/serviceaccount/namespace":"default","kubernetes.io/serviceaccount/secret.name":"default-token-bxzg6","kubernetes.io/serviceaccount/service-account.name":"default","kubernetes.io/serviceaccount/service-account.uid":"a96a30e3-3ee0-44cf-

99b2-1ad4bdbc7632",

"sub":"system:serviceaccount:default:default"

}


 

普通用户有多种方式携带认证信息去访问    APIServer。以客户端证书的方式为例,请求中如果携带了客户端证书,并且证书是由集群的 CA证书(Certification   Authority)签发的,那么这个请求的认证会通过,它会使用证书中的 Subject字段作为用户的名称。代码清单 2-61是一个证书的示例,示例中携带的用户名是kcp(Subject:O=system:kcp,CN=kcp)。

Certificate:

Data:

Version:3(0x2)SerialNumber:

08:e2:5b:3a:2c:8c:6c:06:80:f8:aa:1b:81:76:93:4f

SignatureAlgorithm:sha256WithRSAEncryptionIssuer:CN=kubernetes

Validity

NotBefore:Mar305:59:422021GMT

NotAfter:Jul1109:37:382030GMT

Subject:O=system:kcp,CN=kcp


......

 

2. 认证策略

 

(1)       X509 客户端证书认证

客户端证书认证是双向认证,服务器端需要验证客户端证书的正确性,客户端需要验证服务器端证书的正确性。客户端证书认证方式可以通过Kube-Apiserver的--client- ca-file参数启用,它指向的文件用来验证提供给API服务器的客户端证书。当请求中携带的客户端证书通过了认证时,请求关联的用户名就是证书中的Subject字段的内容。我们可以使用代码清单 2-62查看证书内容


opensslx509-in< 证书-text-noout

(2)      静态 Token文件

静态 Token文件认证方式可以通过 --token-auth-file 参数启用,在这个文件中存放着没有时间限制的 BearerToken,如果想变更 Token,则必须要重启 APIServer。代码清单 2-63是一个 Token文件的示例,每一行包括 Token、用户名和用户ID。JGaOWpJuyBL8NXmeA9V341JOCkHJbOTf,system:kubectl-kcpm1,system:kubectl-kcpm1

访问 APIServer时在HTTP请求头上加入 Authorization的请求头, 值的格式是Bearer<Token>,上面的Token见代码清单 2-64。

curl-H"Authorization:BearerJGaOWpJuyBL8NXmeA9V341JOCkHJbOTf"-khttps://127.0.0.1:6443/

 

(3)       引导 Token

我们在创建集群或是将新节点加入集群时,新节点上的组件要与APIServer进行通信(如Kubelet,但通信需要证书,手动签发证书比较麻烦。为了简化这个过程,Kubernetes1.4后的版本会通过新节点发送请求的方式为新节点签发证书。而发送请求获取证书的请求时使用BearerToken叫作BootstrapToken,这种Token在Kube-SystemNamespace下有一个对应的Secret。Controller-Manager中有一个TokenCleaner的Controller,它会将那些已经过期的 BootstrapToken掉。

Token的格式是 [a-z0-9]{6}.[a-z0-9]{16},Token的前半部分是 TokenID,通过前半部分能找到 UI应的 Secret;第二部分是 TokenSecret,保存在 Secret中。以Kubeadm创建的 tokencwb0ly.cqdj5l0k2qa19evv为例,在 Kube-System的 Namespace下会有一个名字为 bootstrap-token-cwb0ly的 Secret,内容见代码清单2-65。

apiVersion:v1data:

auth-extra-groups:system:bootstrappers:kubeadm:default-node-tokenexpiration:2021-03-13T13:44:23+08:00

token-id:cwb0ly

token-secret:cqdj5l0k2qa19evvusage-bootstrap-authentication:trueusage-bootstrap-signing:true

kind:Secretmetadata:

manager:kubeadm

operation:Update


name:bootstrap-token-cwb0lynamespace:kube-system

使用该 Token作为 Authorization请求头访问 APIServer,请求认证通过后关联到的用户名的格式是 bootstrap-token-<token-id>,即 system:bootstrap:cwb0ly,请求示例见代码清单 2-66。


curl-H"Authorization:Bearercwb0ly.cqdj5l0k2qa19evv"-khttps://127.0.0.1:6443/

要想使用引导 Token 认证,需要在 APIServer 启动的时候添加 --enable-bootstrap-token-auth启动参数,如果想使用 TokenClearController,需要在 Controller-Manager的启动参数中添加 --controllers=*,tokencleaner。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: