k8s之ServiceAccount
导读
上一篇说了k8s的RBAC授权模式，今天就来简单看一下其中涉及到的ServiceAccount。
简介
k8s创建两套独立的账号系统，原因如下：
（1）User账号给用户用，Service Account是给Pod里的进程使用的，面向的对象不同
（2）User账号是全局性的，Service Account则属于某个具体的Namespace
（3）User账号是与后端的用户数据库同步的，创建一个新用户通常要走一套复杂的业务流程才能实现，Service Account的创建则需要极轻量级的实现方式，集群管理员可以很容易地为某些特定任务创建一个Service Account
（4）对于一个复杂的系统来说，多个组件通常拥有各种账号的配置信息，Service Account是Namespace隔离的，可以针对组件进行一对一的定义，同时具备很好的“便携性”
Controller Manager创建了ServiceAccount Controller和Token Controller这两个安全相关的控制器。其中ServiceAccount Controller一直监听Service Account和Namespace的事件，如果在一个Namespace中没有default Service Account，那么Service Account会给Namespace创建一个默认（default）的Service Account。
如果Controller manager进程在启动时指定API Service私钥（service-accountprivate-key-file参数），那么Controller manager会创建Token Controller，Token Controller也监听Service Account事件。
当我们在API Server的鉴权过程中启用了Service Account类型的准入控制器，即在kube-apiserver启动参数中包括下面的内容时：
--admission_control=ServiceAccount
则针对Pod新增或修改的请求，Service Account准入控制器会验证Pod里的Service Account是否合法：
（1）如果spec.serviceAccount域没有被设置，则Kubernetes默认为其指定名称为default的Service Account。
（2）如果指定了spec.serviceAccountName并且不是default，如果此Service Account不存在，则该Pod操作失败。
（3）如果在Pod中没有指定ImagePullSecrets，那么这个spec.serviceAccount域指定的Service Account的ImagePullSecrets会自动加入到该Pod中。
（4）给Pod添加一个特殊的Volume，在该Volume中包含ServiceAccount Secret中的Token，并将Volume挂载到Pod中所有容器的指定目录下（/var/run/secrets/kubernetes.io/serviceaccount）。
ServiceAccount
ServiceAccount是一种账号，给运行在Pod里面的进程提供必要的身份证明。
做过业务系统的同学应该都知道系统中会有一种叫做角色的定义，角色是拥有某些权限的集合，而上一篇说到的Role就是这个角色，而这个ServiceAccount就相当于是拥有某个角色的账号，也就拥有了某些权限。
为了确保k8s集群的安全，API Server都会对客户端进行安全认证。在Pod中访问API Server服务时，是以Service方式访问名为Kubernetes这个服务的，是以类似HTTP Token的新认证方式：Service Account Auth，Pod在调用API Server时，在Http Header中传递了一个Token字符串，类似于之前提到的Http Token认证方式，有以下几处不同：
（1）Token内容来自Pod指定路径下的一个文件（文件名为token），由Kubernetes Controller进程用API Server的私钥（--service-account-private-zkey-file指定的私钥）签名指定生成的一个JWT Secret。
（2）通过HTTPS方式与API Server建立连接后，会用Pod里指定路径下的一个CA证书（文件名为ca.crt）验证API Server发来的证书，验证是否为CA证书签名的合法证书。
（3）API Server收到Token后，采用自身私钥（service-accountkey-file指定，如果没有指定，则默认采用tls-private-key-file指定的参数）对Token进行合法性验证。
上面的认证过程中所涉及的Pod中的以下三个文件：token、ca.crt、namespace，三个文件都在/run/secrets/kubernetes.io/serviceaccount目录下
这三个文件由于参与到Pod进程和API Server认证的过程中，起到了类似Secret（私密凭据）的作用，所以被称为Kubernetes Secret对象，Secret从属于Service Account资源对象，一个Service Account对象里面可以包括多个不同的Secret对象，分别用于不同目的的认证活动。
一个Secret也是有这三样东西：
查看Service Account详细信息
kubectl describe serviceaccounts
查看Secret
kubectl get secrets
在每个Namespace下都有一个名为default的默认Service Account对象，在这个ServiceAccount里面有一个名为Tokens的可以当做Volume被挂载到Pod里的Secret，当Pod启动时，这个Secret会自动被挂载到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权。
一个ServiceAccount可包含多个Secret
其中
（1）名为Tokens的Secret用于访问API Server的Secret，也被称为Service Account Secret。
（2）名为imagePullSecrets的Secret用于下载容器镜像时的认证过程，通常镜像库运行在Insecure模式下，所以这个为空
（3）用户自定义的其他Secret，用于用户的进程。
如果一个Pod在定义时没有指定spec.serviceAccountName属性，则会默认赋值为default，可进行如下指定：
apiVersion: v1
kind: Pod
metadata:
name: pod
spec:
containers:
- name: podtest
image: nginx
serviceAccountName: myServiceAccount
创建ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-admin
namespace: kube-system
将这个ServiceAccount跟ClusterRole进行绑定：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard-admin
labels:
k8s-app: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard-admin
namespace: kube-system
这样ServiceAccount就拥有了ClusterRole的权限
在Pod中使用ServiceAccount
apiVersion: v1
kind: Pod
metadata:
name: pod
namespace: kube-system
spec:
containers:
- name: podtest
image: nginx
serviceAccountName: kubernetes-dashboard-admin
===============================
我是Liusy，一个喜欢健身的程序员。
欢迎关注微信公众号【上古伪神】，一起交流Java技术及健身，获取更多干货，领取Java进阶干货，领取最新大厂面试资料，一起成为Java大神。
来都来了，关注一波再溜呗。
