1 kubernetes API 访问控制

（1）Authentication（认证）

• 认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式
• Kubernetes集群有两类用户：由Kubernetes管理的Service Accounts （服务账户）和（Users Accounts）普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在

（2）Authorization（授权）

• 必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式现共有6种，AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node。默认集群强制开启RBAC

（3）Admission Control（准入控制）

• 用于拦截请求的一种方式，运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验

访问k8s的API Server的客户端主要分为两类：

（1）kubectl ：用户家目录中的 .kube/config 里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。

（2）pod：Pod中的进程需要访问API Server，如果是人去访问或编写的脚本去访问，这类访问使用的账号为：UserAccount；而Pod自身去连接API Server时，使用的账号是：ServiceAccount，生产中后者使用居多

• UserAccount与serviceaccount： 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。用户账户是全局性的，其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离； 服务账户是 namespace 隔离的，通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。

kubectl向apiserver发起的命令,采用的是http方式,其实就是对URL发起增删改查的操作

api和apis的区别是：

• api它是一个特殊链接,只有在核心v1群组中的对象才能使用
• apis 它是一般API访问的入口固定格式名

2 私有仓库的认证

（1）应用文件：kubectl apply -f pod3.yml

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
    - name: redis-photo
      image: reg.westos.org/linux/redis-photon

• 创建pod所需的镜像在私有仓库中

• 查看pod的信息：kubectl get pod，私有仓库镜像拉取失败

• 查看pod的详细信息：kubectl describe pod pod，镜像拉取失败的原因可能是私有仓库没有认证

• 查看sa的信息：kubectl get sa

拉取私有仓库的两种方法：

（1）在Pod指定imagePullSecrets

（2）将认证信息添加到serviceAccount中

• 将认证信息添加到serviceAccount中，要比直接在Pod指定imagePullSecrets要安全很多

2.1 创建serviceaccount

（1） 创建admin的sa： kubectl create serviceaccount admin

• 查看admin的sa的信息，Image pull secrets为空，此时k8s为用户自动生成认证信息，但没有授权

kubectl get sa admin
kubectl describe sa admin 

2.2 添加secrets到serviceaccount中

（1）查看secrets的信息：kubectl get secrets ，其中的myregistrykey是私有仓库的认证信息，在前面的实验中创建的

（2）将myregistrykey添加到serviceaccount的admin的imagePullSecrets

kubectl patch serviceaccount admin -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

2.3 绑定serviceaccount和pod

（1） 应用文件：kubectl apply -f pod3.yml

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
    - name: redis-photo
      image: reg.westos.org/linux/redis-photon
  serviceAccountName: admin

（2）查看pod的信息：kubectl get pod，私有仓库的镜像拉取成功，pod正常运行

• 查看pod的详细信息：kubectl describe pod pod

3 创建UserAccount

（1）进入k8s存放证书以及密钥的目录：cd /etc/kubernetes/pki/

（2）生成密钥：openssl genrsa -out test.key 2048

（3）生成认证请求：openssl req -new -key test.key -out test.csr -subj "/CN=test"

（4）生成自签证书：

openssl  x509 -req -in test.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out test.crt -days 365

• 在当前目录生成相应的认证文件

（5）设置客户端认证参数

kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true

• 查看当前节点的kubeconfig配置信息：kubectl config view

（6）创建test@kubernetes，包含集群名称和访问集群的用户名字

kubectl config set-context test@kubernetes --cluster=kubernetes --user=testContext "test@kubernetes" created.

• 切换集群： kubectl config use-context test@kubernetes
• 查看当前节点的kubeconfig配置信息：kubectl config view

• 查看pod的信息，此时用户通过认证，但还没有权限操作集群资源，需要继续添加授权

4 RBAC-基于角色的访问控制

4.1 RBAC的基本概念

（1） 什么是RBAC（基于角色的访问控制）？

• 让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制

• RBAC（Role Based Access Control）：基于角色访问控制授权。允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。 RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可

• RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

   Role：角色，其实是定义一组对Kubernetes资源（NameSpace级别）的访问规则。
   RoleBinding：角色绑定，定义了用户和角色的关系。
   ClusterRole：集群角色，其实是定义一组对Kubernetes资源（集群级别）的访问规则。
   ClusterRoleBinding：集群角色绑定，定义了用户和集群角色的关系。
   Role和ClusterRole指定了可以对哪些资源做哪些动作，RoleBinding和ClusterRoleBinding将角色绑定到特定的用户、组或ServiceAccount上。
  

（2）RBAC的三个基本概念：

• Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount
• Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
• RoleBinding：定义了“被作用者”和“角色”的绑定关系。RoleBinding仅仅对当前名称空间有对应的权限

（3）Role 和 ClusterRole

• Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限
• ClusterRole 跟 Role 类似，但是可以在集群中全局使用
• ClusterRole和ClusterRoleBinding不用定义namespace字段
• ClusterRole和ClusterRoleBinding控制的是集群级别的权限

（4）常见的资源： Pods，ConfigMaps ， Deployments,Nodes， Secrets， Namespaces，StatefulSets，DaemonSets，Ingress，Volumes，Services，Persistents等

（5）常见的权限： create，get，delete，list，update，edit，watch，exec，patch，proxy，redirect

4.2 RBAC的工作原理

在k8s的授权机制当中，采用RBAC的方式进行授权，其工作原理是：

（1）把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限

（2）如果通过rolebinding绑定role，只能对rolebinding所在的名称空间的资源有权限，上图user1这个用户绑定到role1上，只对role1这个名称空间的资源有权限，对其他名称空间资源没有权限，属于名称空间级别的；

（3）另外，k8s为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将User2通过ClusterRoleBinding到ClusterRole，从而使User2拥有集群的操作权限

4.3 实验示例

（1）应用文件： kubectl apply -f role.yml ，创建角色

• 定义角色：在定义角色时会指定此角色对于资源的访问控制的规则

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default  ## 默认的命名空间
  name: myrole  ## 角色名
rules:
 - apiGroups: [""] 
  resources: ["pods"]  ## 对pods的权限为verbs中的内容
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]

• 查看角色： kubectl get role
• 查看myrole的详细信息：kubectl describe role myrole

（2）应用文件：kubectl apply -f role.yml ，角色绑定

• 绑定角色：将主体与角色进行绑定，对用户进行访问授权
• RoleBinding可以引用在同一命名空间内定义的Role对象。
• 定义的RoleBinding对象在”default”命名空间中将”test-read-pods”角色授予用户”myrole”。这一授权将允许用户”role”从”default”命名空间中读取pod

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-read-pods
  namespace: default  ## 作用的命名空间
subjects:
 - kind: User
  name: test  ## 定义主体，将角色绑定到test
  apiGroup: rbac.authorization.k8s.io
roleRef:  ## 绑定的角色
  kind: Role
  name: myrole
  apiGroup: rbac.authorization.k8s.io

• 查看角色绑定的信息：

kubectl get rolebindings.rbac.authorization.k8s.io 
kubectl describe rolebindings.rbac.authorization.k8s.io 

• 切换集群：kubectl config use-context test@kubernetes，完成角色绑定后，test具有myrole角色的权限，但是RoleBinding仅仅对当前名称空间有对应的权限

kubectl get  pod
kubectl get pod -n kube-system

• 切换集群：kubectl config use-context kubernetes-admin@kubernetes
• 系统集群具有查看其他的命名空间的权限：kubectl get pod -n kube-system

（3）创建集群角色

• 应用文件：kubectl apply -f role.yml

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myclusterrole ## 集群角色
rules:
 - apiGroups: [""]
  resources: ["pods"]  ## pod资源权限
  verbs: ["get", "watch", "list", "delete", "create", "update"]
 - apiGroups: ["extensions", "apps"]
  resources: ["deployments"]  ## deployments权限
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

• 查看mycluster的信息：kubectl get clusterrole|grep mycluster，集群角色创建成功

（4）集群角色绑定：kubectl apply -f role.yml

• RoleBinding对象也可以引用一个ClusterRole对象用于在RoleBinding所在的命名空间内授予用户对所引用的ClusterRole中
  定义的命名空间资源的访问权限

## 以下角色绑定定义将允许用户"test"从"default"命名空间中读取pod和deployment
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rolebind-myclusterrole
  namespace:  default  ## 仅作用于当前的namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: test

• 切换集群：kubectl config use-context test@kubernetes，集群角色只能访问默认名空间的pod和deployment的权限
  

• 查看其他命名空间的信息：kubectl -n kube-system get all
  

（5）ClusterRoleBinding

• 可以使用ClusterRoleBinding在集群级别和所有命名空间中授予权限。下面示例中所定义的ClusterRoleBinding 允许在用户组”myclusterrole”中的“test”用户可以读取集群中任何命名空间中的pod和deployment

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: clusterrolebinding-myclusterrole
roleRef:  ## 绑定的集群角色
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:    ## 绑定的主体test
 - apiGroup: rbac.authorization.k8s.io
  kind: User
  name: test

• 切换集群：kubectl config use-context test@kubernetes
• 查看pod的：kubectl -n kube-system get pod

• 查看deployment控制器的信息

kubectl -n kube-system get deployments.apps

• 查看kube-system 命名空间的所有信息：kubectl -n kube-system get all，“test”用户只可以读取集群中任何命名空间中的pod和deployment

5 服务账户的自动化

服务账户准入控制器（Service account admission controller）

如果该 pod 没有 ServiceAccount 设置，将其 ServiceAccount 设为 default。
保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
如果 pod 不包含 ImagePullSecrets 设置，那么 将 ServiceAccount 中的 ImagePullSecrets 信息添加到 pod 中。
将一个包含用于 API 访问的 token 的 volume 添加到 pod 中。
将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中。

Token 控制器（Token controller）

检测服务账户的创建，并且创建相应的 Secret 以支持 API 访问。
检测服务账户的删除，并且删除所有相应的服务账户 Token Secret。
检测 Secret 的增加，保证相应的服务账户存在，如有需要，为 Secret 增加 token。
检测 Secret 的删除，如有需要，从相应的服务账户中移除引用。

服务账户控制器（Service account controller）

服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户

Kubernetes 还拥有“用户组”（Group）的概念：

• ServiceAccount对应内置“用户”的名字是： system:serviceaccount:<ServiceAccount名字 >
• 而用户组所对应的内置名字是： system:serviceaccounts:<Namespace名字 >

Kubernetes 还提供了四个预先定义好的 ClusterRole 来供用户直接使用：

cluster-amdin：拥有集群的全部权限
admin：拥有一个命名空间全部权限
edit：拥有修改资源的权限
view：拥有查看资源的权限

• kubernetes中有一个默认的的clusterrole:view，就是一个只有只读权限的角色

kubectl describe clusterrole view

• 修改资源的权限：kubectl describe clusterrole edit

• 拥有一个命名空间全部权限：kubectl describe clusterrole admin

• 拥有集群的全部权限：kubectl describe clusterrole cluster-admin