kubernetes(k8s)：访问控制（认证+授权+准入控制）

1. kubernetes API 访问控制

官方文档：
https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/
kubernetes api分为：认证、授权、准入控制
用户通过 kubectl、客户端库或者通过发送 REST 请求访问 API。 用户（自然人）和 Kubernetes 服务账户 都可以被授权进行 API 访问。 请求到达 API 服务器后会经过几个阶段，具体说明如图：
由上图来介绍一下 Kubernetes API 的请求从发起到其持久化入库 的一个流程。

首先看一下请求的发起，请求的发起分为两个部分：

1. 第一个部分是人机交互的过程。 是大家非常熟悉的用 kubectl 对 apiserver 的一个请求过程；
2. 第二个部分是 Pod 中的业务逻辑与 apiserver 之间的交互。

当我们的 apiserver 收到请求后，就会开启访问控制流程。这里面分为三个步骤：

1. Authentication 认证阶段：判断请求用户是否为能够访问集群的合法用户。如果用户是个非法用户，那 apiserver会返回一个 401 的状态码，并终止该请求；
2. 如果用户合法的话，我们的 apiserver 会进入到访问控制的第二阶段 Authorization：授权阶段。在该阶段中apiserver 会判断用户是否有权限进行请求中的操作。如果无权进行操作，apiserver 会返回 403的状态码，并同样终止该请求；
3. 如果用户有权进行该操作的话，访问控制会进入到第三个阶段：AdmissionControl。在该阶段中 apiserver 的admission controller 会判断请求是否是一个安全合规的请求。如果最终验证通过的话，访问控制流程才会结束。

此时我们的请求将会转换为一个 Kubernetes objects 相应的变更请求，最终持久化到 ETCD 中。

认证（任意一种） -->授权（一般是rbac 和 node）–> 准入控制（自己选择）

2. 认证 Authentication

认证一共有8种，可以启动一种或多种认证方式，只要有一种认证方式通过，就不再对其它方式认证，通常启动X 509 Client Certs和Service Accout Tokens两种认证方式

k8s集群有两类用户： 由k8s管理的Service Accounts 服务帐号和 Users Accounts普通账户，k8s种的帐号是形式上存在的。

默认存在的taken:

1 访问k8s的API Server的客户端

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

• kubectl ：用户家目录中的 .kube/config 里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。
• pod：Pod中的进程需要访问API Server，如果是人去访问或编写的脚本去访问，这类访问使用的账号为：UserAccount；而Pod自身去连接API Server时，使用的账号是：ServiceAccount，生产中后者使用居多。

[kubeadm@server1 ~]$ cd .kube/   // 用户主目录下的认证文件
[kubeadm@server1 .kube]$ ls
cache  config  http-cache
[kubeadm@server1 .kube]$ cat config
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EUXhOekV5TWprME5Wb1hEVE13TURReE5URXlNamswTlZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTndICnI0cmVweEEzVTdpRXlkb3MwSHU4WmM5QnBGZW5ocVdwMjgxdmJQNUNOUEkxbG15R2J0V3l2TFBZdTk4UHVXK2YKTFhleEd4bUQvUm9nZmo0UVhYaDBRbTBKVlN6dEZIeFRnb1VobEgyd2REd0JhSFAxaUpybm5CNmx0c2tRZjVIaApPanhXVUtYVWtEZkxHcllRM3dzV0c5T1oxNDI0MEViUko3Q1NBUkwxd1ZkdDc5djZmNHRCUnRtWEN4SUFFUnFHCmpwRVJDMFh4ZU8xMU9rQTA1SjlJNjRHNXpybkxvOHVYV3JyaE5kOE53V3V6d3NQZ1F2V3NaejVudElHd3haR1QKcURjN25lMXU1c01TcHZMZG03UjgreHVIemxiZkpKNDdkSjc3QURXZXZ4WnY1UkNUeE5mSm9lOXpkdUNoV2pLdQpmWFNONXpKVUV3K25OSjJWOFFrQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFCV3FpSnVKZXRyQmZ4NWtFb3NaUlYySXMyeEEKMWRhdW43WlJGbHYvT0xDTzJaZWVJNnlTRWpHU1hkWXpYZUREbnFoWHh0cy8zOFkvaVNXSFY3Z1JEdTJxbXpnZgp3a0hoK1pwci80WHgxMm5rL011dFRBUjNwMmJHRkFDM2djNUh1YWFma2ZnNldvc1ArdklxSkFjdXFjbkxqenZwCm5TVjlON0Y3dnNVeXdtSmIrV3hMaXY2VmgzbFRQMUJuck15aG5iVFA5bHhvK0hEOU9wUC9yTStvcEw0NXhrb0wKOXgrWHo5RXpDR29RUXpFT09nZUg3WW1tUFlvSXUzY0FKOG10dGtGNHpzTHRid1RiT2J2bGhsYmFqbWY4VXNEagptYnA4Vm0rYVNrS0p4SWhPVXlGcHlxQWRTQ3dxYUpjajNuQlRPdWJmV1VIeHAvYzI4dmladjRaVHA0az0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=

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

kubectl proxy --port=8888 &                   // 代理
curl http://localhost:8888/api/v1/namespaces/default
curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments

以上两种api的区别是：

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

2 UserAccount 与 serviceaccount

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

2.1 创建serviceaccount：

[kubeadm@server1 ~]$ kubectl create serviceaccount test
serviceaccount/test created

[kubeadm@server1 ~]$ kubectl get sa
NAME                     SECRETS   AGE
default                  1         19d
nfs-client-provisioner   1         3d7h
test                     1         10s

[kubeadm@server1 ~]$ kubectl describe sa test  //此时k8s为用户自动生成认证信息，但没有授权
Name:                test
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   test-token-nxqrn
Tokens:              test-token-nxqrn
Events:              <none>

2.2 添加secrets到serviceaccount中

博客 中创建的kubernetes.io/dockerconfigjson类型的sercets：myregistrykey用于存储docker registry的认证信息

[kubeadm@server1 ~]$ kubectl patch serviceaccount test -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
serviceaccount/test patched

[kubeadm@server1 ~]$ kubectl describe sa test
Name:                test
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  myregistrykey  //可以读取拉取镜像的秘钥
Mountable secrets:   test-token-nxqrn
Tokens:              test-token-nxqrn
Events:              <none>

2.3 把serviceaccount和pod绑定起来

让test对私有仓库进行认证

[kubeadm@server1 auth]$ cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: reg.westos.org/westos/game2048
    ports:
    - name: http
      containerPort: 80
  serviceAccountName: test

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

2.4 创建useraccount

[root@server2 pki]# cd /etc/kubernetes/pki/   // 证书的存放位置
[root@server2 pki]# ll . -d  // 只允许超户写入
drwxr-xr-x 3 root r