k8s认证及ServiceAccount-十五
一、ServiceAccount
(1)简介
https://www.kubernetes.org.cn/service-account
Service Account为Pod中的进程和外部用户提供身份信息。所有k8s集群中账户分为两类，k8s管理的serviceaccount(服务账户)和useraccount（用户账户）。
大家都知道api server是集群的入口，对于kunbernetes的api server 是肯定不能随便访问。所以我们必须需要一些认证信息。例如：
当用户访问集群（例如使用kubectl命令）时，apiserver 会将您认证为一个特定的 User Account（目前通常是admin，除非您的系统管理员自定义了集群配置）。
Pod 容器中的进程也可以与 apiserver 联系。 当它们在联系 apiserver 的时候，它们会被认证为一个特定的 Service Account。
因为kubernetes是高度模块化，所有认证方式和授权方式都可以通过插件的方式让客户自定义的，可以支持很多种。客户端请求的时候首先需要进行认证，
认证通过后再进行授权检查，因有些操作需要级联到其他资源或者环境，但是级联环境是否有授权权限，这时候需要准入控制。
Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同
- User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API而设计；
- User account是跨namespace的，而service account则是仅局限它所在的namespace；
- 每个namespace都会自动创建一个default service account
- Token controller检测service account的创建，并为它们创建secret
- 开启ServiceAccount Admission Controller后
- 每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccout）
- 验证Pod引用的service account已经存在，否则拒绝创建
- 如果Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中
- 每个container启动后都会挂载该service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/
当创建 pod 的时候，如果没有指定一个 service account，系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。而pod和apiserver之间进行通信的账号，称为serviceAccountName。
从上面截图可看到每个Pod都会有个存储卷，这个存储卷为token令牌，这就是pod和serviceaccount认证信息。通过secret进行定义，由于认证信息属于敏感信息，所以需要保存在secret资源当中，并以存储卷的方式挂载到Pod当中。从而让Pod内运行的应用通过对应的secret中的信息来连接apiserver，并完成认证。每个 namespace 中都有一个默认的叫做 default 的 service account 资源。进行查看名称空间内的secret，也可以看到对应的default-token。让当前名称空间中所有的pod在连接apiserver时可以使用认证信息，从而保证pod之间的通信。
(2)创建方式
默认的service account 仅只能获取当前Pod自身的相关属性，无法观察到其他名称空间Pod的相关属性信息。如果想要扩展Pod，假设有一个Pod需要用于管理其他Pod或者是其他资源对象，是无法通过自身的名称空间的serviceaccount进行获取其他Pod的相关属性信息的，此时就需要进行手动创建一个serviceaccount，并在创建Pod时进行定义。实际上，service accout也属于一个k8s资源，如下查看service account的资源定义字段：
[root@k8s-master ~]# kubectl explain sa
k8s的命令行create，封装了很多资源创建命令：
[root@master ~]# kubectl create serviceaccount -h #查看帮助
[root@master ~]# kubectl create serviceaccount mysa -o yaml --dry-run
--dry-run：验证是否能创建，但不会真的创建
-o yaml：输出为yaml，这样可以快捷的得到yaml文件，甚至改改就能用了
(3)创建
[root@master ~]# kubectl create serviceaccount admin #创建一个名为admin的sa
查看这个sa：
可以看到有一个 token 已经被自动创建，并被 service account 引用。
(4)serviceaccount的自定义使用
现在创建pod时都时使用默认serviceaccount的，要设置使用非默认的 service account，只需要在 pod 的spec.serviceAccountName 字段中将name设置为您想要用的 service account 名字即可。在 pod 创建之初 service account 就必须已经存在，否则创建将被拒绝。需要注意的是不能更新已创建的 pod 的 service account。
创建pod，并使用自定义serviceaccount：
a、定义pod资源清单
[root@master manifests]# vim pod-sa-demo.yaml
b、创建
c、查看
由token可见已经使用了上面定义的serviceaccount；
(5)自建证书和账号进行访问apiserver
在K8S集群当中，每一个用户对资源的访问都是需要通过apiserver进行通信认证才能进行访问的，那么在此机制当中，对资源的访问可以是token，也可以是通过配置文件的方式进行保存和使用认证信息，可以通过kubectl config进行查看配置；
[root@master ~]# kubectl config view
(1)生成证书
(2)使用ca.crt进行签署
a、证书签署请求
[root@master pki]# openssl req -new -key magedu.key -out magedu.csr -subj "/CN=magedu" #magedu就是用户
b、证书签署
[root@master pki]# openssl x509 -req -in magedu.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out magedu.crt -days 365
[root@master pki]# openssl x509 -in magedu.crt -text -noout #查看证书信息
c、添加到用户认证
[root@master pki]# kubectl config set-credentials magedu --client-certificate=./magedu.crt --client-key=./magedu.key --embed-certs=true
User "magedu" set.
[root@master pki]# kubectl config set-context magedu@kubernetes --cluster=kubernetes --user=magedu
Context "magedu@kubernetes" created.
d、查看kubectl配置信息
(3)尝试切换到magedu用户
[root@master pki]# kubectl config use-context magedu@kubernetes #切换用户
当切换到magedu用户进行访问集群时，由于magedu账户没有管理集群的权限，所以在获取pods资源信息时，会提示Forrbidden。
那么接下来就可以学习一下怎么对账户进行授权；
[root@master pki]# kubectl config use-context kubernetes-admin@kubernetes #再把用户切换回kubernetes
