k8s的认证授权

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

Authorization（授权）

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

Admission Control（准入控制）

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

UserAccount与ServiceAccount

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

1 ServiceAccount

服务账户控制器（Service account controller）
- 服务账户管理器管理各命名空间下的服务账户
- 每个活跃的命名空间下存在一个名为 “default” 的服务账户
服务账户准入控制器（Service account admission controller）
- 相似pod中 ServiceAccount默认设为 default。
- 保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
- 如果pod不包含ImagePullSecrets设置那么ServiceAccount中的ImagePullSecrets 被添加到pod中
- 将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中
- 将一个包含用于 API 访问的 token 的 volume 添加到 pod 中

RBAC（Role Based Access Control）

基于角色访问控制授权：

- 允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。

- RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可

- RBAC的三个基本概念

- Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount

- Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。

- RoleBinding：定义了“被作用者”和“角色”的绑定关系

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

- Role 和 ClusterRole

- Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限。

- ClusterRole 跟 Role 类似，但是可以在集群中全局使用。

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

- cluster-amdin、admin、edit、view

演示ServiceAccount

先在hub仓库创建一个私有的项目，不勾选公开

上传一个镜像

[root@k8s-master ~]# docker tag nginx/nginx  reg.mqw.org/mqw/nginx

[root@k8s-master ~]# docker push reg.mqw.org/mqw/nginx

Using default tag: latest
The push refers to repository [reg.mqw.org/mqw/nginx]
5f0272c6e96d: Pushed 
f4f00eaedec7: Pushed 
55e54df86207: Pushed 
ec1a2ca4ac87: Pushed 
8b87c0c66524: Pushed 
72db5db515fd: Pushed 
9853575bc4f9: Pushed 
latest: digest: sha256:127262f8c4c716652d0e7863bba3b8c45bc9214a57d13786

运行该私有仓库的镜像，因为在创建pod时会镜像下载会受阻，因为docker私有仓库下载镜像需要认证

[root@k8s-master ~]# kubectl run web --image reg.mqw.org/mqw/nginx

此时就会拉不下来镜像

方法一

创建一个serviceaccount

#sa即为serviceaccount

[root@k8s-master ~]# kubectl create sa mqw

查看

[root@k8s-master ~]# kubectl get sa

NAME      SECRETS   AGE
default   0         9d
mqw       0         2s

也可以查看某个sa的详细信息

[root@k8s-master ~]# kubectl describe sa mqw 

Name:                mqw
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

也可以删除

[root@k8s-master ~]# kubectl get sa

NAME        SECRETS   AGE
default     0         9d
mm          0         45s
mqw         0         20s
timinglee   0         10s

[root@k8s-master ~]# kubectl delete sa mm

serviceaccount "mm" deleted

[root@k8s-master ~]# kubectl get sa

NAME        SECRETS   AGE
default     0         9d
mqw         0         31s
timinglee   0         21s

建立secrets

[root@k8s-master ~]# kubectl create secret docker-registry docker-login --docker-username admin --docker-password 123 --docker-server reg.mqw.org --docker-email lee@timinglee.org

查看

[root@k8s-master ~]# kubectl describe secrets docker-login 

Name:         docker-login
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/dockerconfigjson

Data
====
.dockerconfigjson:  113 bytes

将secrets注入到sa中

[root@k8s-master ~]# kubectl edit sa  mqw

此时查看就会发现imagepullsecrets

pod绑定sa

编写yaml文件

[root@k8s-master ~]# mkdir sercive
[root@k8s-master ~]# cd sercive/
[root@k8s-master sercive]# ls
[root@k8s-master sercive]# vim q1.yml

启动，并查看。就会运行了私有项目里的镜像

[root@k8s-master sercive]# kubectl apply -f q1.yml 
pod/web created

[root@k8s-master sercive]# kubectl get pod

NAME   READY   STATUS    RESTARTS   AGE
web    1/1     Running   0          6s

方法二

因为他本身自带了一个default

编辑该文件

[root@k8s-master sercive]# kubectl edit sa default

查看

运行私有项目

[root@k8s-master sercive]# kubectl run w --image reg.mqw.org/mqw/nginx

此时也会运行

认证(在k8s中建立认证用户)

创建UserAccount

切换目录

使用 OpenSSL 生成一个私钥文件

[root@k8s-master pki]# openssl genrsa -out timinglee.key 2048

查看

创建证书签署请求

[root@k8s-master pki]# openssl req  -new -key timinglee.key -out timinglee..csr -subj "/CN=timinglee"

查看

签署证书

[root@k8s-master pki]# openssl x509 -req  -in timinglee..csr -CA ca.crt -CAkey ca.key -CAcreateserial  -out timinglee.crt -days 365

查看

建立k8s中的用户

[root@k8s-master pki]# kubectl config set-credentials timinglee --client-certificate /etc/kubernetes/pki/timinglee.crt --client-key /etc/kubernetes/pki/timinglee.key --embed-certs=true

查看

为用户创建安全上下文

[root@k8s-master pki]# kubectl config set-context timinglee@kubernetes --cluster kubernetes --user timinglee

切换用户，

[root@k8s-master pki]# kubectl config use-context timinglee@kubernetes

但因为用户在集群中只有用户身份没有授权，没有任何的权力

#如果需要删除用户

[root@k8s-master pki]# kubectl config delete-user timinglee
deleted user timinglee from /etc/kubernetes/admin.conf

切换会管理员用户

[root@k8s-master pki]# kubectl config use-context kubernetes-admin@kubernetes

1，role授权实施

创建一个目录，生成role的yaml文件

[root@k8s-master pki]# cd
[root@k8s-master ~]# mkdir role
[root@k8s-master ~]# cd role
[root@k8s-master ~]# kubectl create role myrole --dry-run=client --verb=get --resource pods -o yaml > myrole.yml

给他多点权限

[root@k8s-master role]# vim myrole.yml

启动

[root@k8s-master role]# kubectl apply -f myrole.yml

可以查看

建立角色绑定

[root@k8s-master role]# kubectl create rolebinding timinglee --role myrole --namespace default --user timinglee --dry-run=client -o yaml  > rolebinding-myrole.yml

[root@k8s-master role]# vim rolebinding-myrole.yml

启动

[root@k8s-master role]# kubectl apply -f rolebinding-myrole.yml

可以查看

切换用户

[root@k8s-master role]# kubectl config use-context timinglee@kubernetes

此时就可以使用pod的，

但支队pod进行了授权，并不能对其他进行任何操作，如果想对其他的进行操作可以在yml文件里添加想要的权限

2，clusterrole授权实施

建立集群角色

[root@k8s-master role]#  kubectl create clusterrole myclusterrole --resource=deployment --verb get --dry-run=client -o yaml > myclusterrole.yml

给予权限

[root@k8s-master role]# vim myclusterrole.yml

启动

[root@k8s-master role]# kubectl apply -f myclusterrole.yml

可以查看

建立集群角色绑定

[root@k8s-master role]# kubectl create clusterrolebinding  clusterrolebind-myclusterrole --clusterrole myclusterrole  --user timinglee --dry-run=client -o yaml > clusterrolebind-myclusterrole.yml

[root@k8s-master role]# vim clusterrolebind-myclusterrole.yml

启动

[root@k8s-master role]# kubectl apply -f clusterrolebind-myclusterrole.yml

可以查看

测试

切换用户

[root@k8s-master role]# kubectl config use-context timinglee@kubernetes

此时也可以进行操作

同理，如果想要其他的操作权限，可以在yml文件里添加

服务账户的自动化

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

如果该 pod 没有 ServiceAccount 设置，将其 ServiceAccount 设为 default。
保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
如果 pod 不包含 ImagePullSecrets 设置，那么将 ServiceAccount 中的 ImagePullSecrets 信息添加到 pod 中。
将一个包含用于 API 访问的 token 的 volume 添加到 pod 中。