有时我们的业务程序也有获取kubernetes集群资源的需求, serviceaccount(简写sa)就是专门给pod用的一种鉴权机制, 在搭建Prometheus或者是fluentd时都会有创建serviceaccount的命令, 如何创建一个serviceaccount, 使其只能操作kube-system下的pods.
什么是service account? 顾名思义,相对于user account(比如:kubectl访问APIServer时用的就是user account),service account就是Pod中的Process用于访问Kubernetes API的account,它为Pod中的Process提供了一种身份标识。相比于user account的全局性权限,service account更适合一些轻量级的task,更聚焦于授权给某些特定Pod中的Process所使用.
在kube-system下创建一个sa
1 | kubectl create sa pod-reader -n kube-system |
该sa会绑定一个secret, 下面需要从该secret中获取token信息
假如该secret 名为pod-reader-token-95cwp
创建role
1 | apiVersion: rbac.authorization.k8s.io/v1 |
创建rolebinding
1 | apiVersion: rbac.authorization.k8s.io/v1 |
创建集群信息
1 | # kubectl命令行下操作 |
我们看到service account并不复杂,只是关联了一个secret资源作为token,该token也叫service-account-token
,该token才是真正在API Server验证(authentication)环节起作用的
在pod yaml中使用serviceaccount
1 | apiVersion: extensions/v1beta1 |
在大多数情况下,我们上线应用并没有手工地指定这个serviceAccount,那又是为何呢?
默认的serviceaccount
在默认情况下, kubernetes会为每一个namespace创建个一个默认的sa, 而且会默认地给所有在该namespace下的pod都自动挂载到/var/run/secrets/kubernetes.io/serviceaccount
下
随便查看一个运行的pod的yaml文件
在pod内查看
这三个文件与上面提到的service account的token中的数据是一一对应的
那么这个pod内的应用就能通过这3个文件与api-server通信了, 根据这个sa具有的权限获取资源.
原理
service account为Pod中的Process提供了一种身份标识,在Kubernetes的身份校验(authenticating)环节,以某个service account提供身份的Pod的用户名为:
1 | system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT) |
以kube-system namespace下的“default” service account为例,使用它的Pod的username全称为:
1 | system:serviceaccount:kube-system:default |
有了username,那么credentials呢?就是上面提到的service-account-token中的token。API Server的authenticating环节支持多种身份校验方式:client cert、bearer token、static password auth等,这些方式中有一种方式通过authenticating(Kubernetes API Server会逐个方式尝试),那么身份校验就会通过。一旦API Server发现client发起的request使用的是service account token的方式,API Server就会自动采用signed bearer token方式进行身份校验。而request就会使用携带的service account token参与验证。该token是API Server在创建service account时用API server启动参数:–service-account-key-file的值签署(sign)生成的。如果–service-account-key-file未传入任何值,那么将默认使用–tls-private-key-file的值,即API Server的私钥(server.key)。
通过authenticating后,API Server将根据Pod username
所在的group:system:serviceaccounts
和system:serviceaccounts:(NAMESPACE)
的权限对其进行authority和admission control两个环节的处理, 最终通过验证及鉴权.