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大神。

来都来了，关注一波再溜呗。