一、Service Account总结

1、service account到底是什么？

• 在k8s中，service account是给集群中的进程使用的，当集群中的pod/进程需要跟apiserver申请调用资源时使用时使用的；我们用户是不会去使用它的；举个很形象的例子，就像nginx服务中的nginx账号一样，我们一般是不会使用su去登录它并且使用它的；如下，就能很直观的明白了：

# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;		#这里这个账户就叫nginx，就是给nginx这个进程、服务使用的
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;

• 但是不同的是，linux中的nginx服务，我们使用yum -y install下载nginx服务时，系统会默认帮我们创建一个叫做nginx的账户；但是在k8s中，任何进程任何pod在被创建出来的同时，如果我们不指定使用自己创建的service account的话，系统会默认给我们使用default账户去创建资源

2、在k8s集群中为什么需要service account？

• 原因很简单，在创建新的资源的同时，限制它们的权限；
• 因为在我们创建新的资源时，如果不指定使用哪个sa去创建的话，默认就是使用default服务账户，但是default这个服务账号权限特别大，任何操作都能执行，在公司中我们是不允许这样的事情发生的；主要的原因就是为了保护资源，防止误删
• 所以这个时候我们就需要用到service account了，对资源限制权限，给它我们想给的权限，这样就能有效的保护好我们资源

3、创建出来的sa可以直接就使用吗？

但是一个sa创建出来了有什么用呢？这个问题值得深思

• 在任何地方一个账号创建出来了，单单从账号本身是没有任何意义的；就像我们去银行开银行卡需要开户一样的，虽然说银行都是有vip和普通用户的，但是单纯的只看账号的话，账号就是一长串的数字而已；在k8s中也是一样的，如果单单只看sa这个账户的话，一个sa被创建出来了，并没有很大的意义的。
• 回归到生活中，为什么银行里面有vip会员，还有更多的普通账户呢？那是因为他们在账户的钱多，钱多了也就变成vip了；那么这跟我们k8s中的sa又有什么关系呢？答案是：有关系的。
• 在k8s集群中的sa，也是需要“充钱”进去才能变成“vip”的，这里面的”钱“，就是我们在集群中所说的角色role了，创建一个角色，赋予它一定的权限；但是我们需要将它跟我们所创建出来的角色绑定在一起，那这个sa就会变成”vip“了，那么这个sa的意义就有了。

4、sa有意义了，我们怎样去使用它？

• 现在是万事俱备只欠东风了，账号有了，权限也有了，那么我们怎样去使用它呢？
• 很简单，只要我们在创建新资源的时候（比如说pod、deployment），在yaml文件中指定使用你想指定的sa账户，就可以了；
• 指定了服务账户之后，我们把pod创建出来了，我们在使用这个pod时，这个pod就有了我们指定的账户的权限了，这样就能达到我们在公司中的需求了。

二、User Account总结

1、在k8s中User Account到底是什么？

• 只要我们理解了前面的service account的话，这里就更容易理解了；前面我们说的service account在k8s集群中是给进程/pod使用的，但是这里我们要讲的User Account，是给我们用户，也就是给人用的
• 其实并不难理解，举个例子就很好的能理解到这个UA在k8s中是什么了：
  • 在linux操作系统中，我们有且仅有一个root账户，还能有若干个普通账户；root账户的权限最大，普通账户如果需要某些特殊的权限的话，是需要我们root账户去给它授权的
  • 而这些给我们提供使用的，在k8s的具体体现，那就是user account

2、为什么需要User Account？

• 在k8s集群中跟linux操作系统是一样的，我们默认的账户是：kubernetes-admin@kubernetes，管理员账户，权限也是最大的，在k8s集群中畅通无阻
• 但是在企业中，并不是只有我们一个人使用k8s集群，还有很多的研发人员都是需要使用集群的；这时我们需要给他们创建一些账号，但是这些账号权限又不能太大，以防误删资源，这个时候我们就能使用user account了

3、怎样创建普通账户？

• 创建普通账户很简单，首先我们要创建一系列的证书文件和密钥文件，如下：

Key 是私用密钥openssl格，通常是rsa算法。

Csr 是证书请求文件，用于申请证书。在制作csr文件的时，必须使用自己的私钥来签署申，还可以设定一个密钥。

crt是CA认证后的证书文，（windows下面的，其实是crt），签署人用自己的key给你签署的凭证。

• 创建完这些文件之后直接在命令行创建普通账户

[root@k8s-master ~]# kubectl  config  set-credentials zh  --client-certificate=./zh.crt  --client-key=./zh.key  --embed-certs=true

4、普通账户有了，可以直接使用么？

• 虽然普通账户已经有了，但是单单一个账户并没有任何意义，需要有权限才行；那权限从何处来？
• 权限就从角色中来，创建完了账户后，我们还并不能直接使用它，使用它也没有任何意义，只是一个空壳而已；这时我们就需要创建一个角色，将角色跟账户互相绑定了，这个账户就有意义了

5、角色到底应该怎样创建？

• 角色主要分为两种：角色和集群角色，角色是比较有限制性的，只针对于指定的资源生效；而集群角色就权限就比较广泛了，新建了一个集群角色之后，这个角色将对整个集群受影响；在使用的过程中，具体情况具体分析，适合哪种就使用哪种

• 可见角色的重要性，那角色到底应该怎样去创建呢？

  • 创建角色role的方法主要有两种：第一种方法是直接通过命令行创建，如下所示：

  • [root@k8s-master ~]# kubectl  create role  myrole  --verb=get,list,watch --resource=pod,svc 
    
    #创建了一个名叫myrole的角色，并且赋予它对pod、service有看的权限
    

  • 第二种方法就是通过yaml文件去创建了，如下，普通角色的yaml文件：

  • apiVersion: rbac.authorization.k8s.io/v1	
    #api版本，使用kubectl explain +【要查询的资源，比如pod】
    kind: Role	
    metadata:
     name: pod-reader
    rules:		#规则
    - apiGroups: [""] 　　　　　　# 空字符串""表明使用支持所有的api版本，一般都放空
      resources: ["pods"]		#resources：资源
      #现在这些权限对哪些资源生效，这里写的是pod，如果想要多写几个，就用逗号隔开，其实就是一个列表
      verbs: ["get", "watch", "list"]	#详细的权限：这三个都是查看的权限
      #verbose：冗长的，详细的，我们常用的有：rpm -ivh，显示详细/冗长信息
      
      
    #这里没有spec，写spec是有规律的，比如我们创建一个pod，pod中还有一个container，container也有它自己的很多重要的属性
    

  • 集群角色的yaml文件，如下：

  • kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1 #会升级的，升级就不能用了
    metadata:	# ClusterRole是集群范围对象，所以这里不需要定义"namespace"字段
     name: secret-reader #这里就跟下面的互相对应
    rules:
    - apiGroups: [""]	
      resources: ["secrets"] #这里写的secrets
      verbs: ["get", "watch", "list"]
    

• 需要注意的是，角色和账户都创建好了，需要将他们俩绑定在一起，账户就会变得有意义，如下：

• [root@k8s-master ~]# kubectl  create  rolebinding myrole-binding  --role=myrole  --user=zh
  

6、万事俱备只欠东风，怎样使用UA？

• 绑定做完了，使用就非常简单了，这个过程就相当于在linux中切换普通账户使用su - user 一样的
• 直接在命令上切换账户即可，语法如下：

[root@k8s-master ~]# kubectl config user-context zh@kubernetes【最后接的是具体账户名】 

#这个账户是k8s中的root用户，叫做admin用户，就是管理员
[root@k8s-master ~]# kubectl config user-context kubernetes-admin@kubernetes