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

我不是女神ヾ 2023-02-12 05:42 2阅读 0赞

### 文章目录 ###

*  1. kubernetes API 访问控制
 *  2. 认证 Authentication
 *   *   *  1 访问k8s的API Server的客户端
         *  2 UserAccount 与 serviceaccount
         *   *  2.1 创建serviceaccount：
             *  2.2 添加secrets到serviceaccount中
             *  2.3 把serviceaccount和pod绑定起来
             *  2.4 创建useraccount
 *  3. 授权 Authorization
 *   *   *  3.1RBAC基于角色访问控制授权
         *  3.2 RoleBinding角色绑定
         *  3.3ClusterRoleBinding集群角色绑定
 *  4. 准入控制 Admission Control
 *  5.服务账户的自动化
 *  6. kubernetes的用户组

# 1. kubernetes API 访问控制 #

官方文档：  
[https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/][https_kubernetes.io_zh_docs_reference_access-authn-authz_controlling-access]  
kubernetes api分为：`认证`、`授权`、`准入控制`  
用户通过 kubectl、客户端库或者通过发送 REST 请求访问 API。 用户（自然人）和 Kubernetes 服务账户 都可以被授权进行 API 访问。 请求到达 API 服务器后会经过几个阶段，具体说明如图：  
![准入控制][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]由上图来介绍一下 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）–> 准入控制（自己选择）  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1][]

# 2. 认证 Authentication #

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

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

默认存在的taken:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]

### 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>

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]

#### 2.2 添加secrets到serviceaccount中 ####

[博客][Link 1] 中创建的`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>

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 4]

#### 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要安全很多。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]

#### 2.4 创建useraccount ####

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

[root@server2 pki]# openssl genrsa -out test.key 2048  // 输出一个2048位的key
    Generating RSA private key, 2048 bit long modulus
    .................................................................+++
    ......................................................................................................................................................................+++
    e is 65537 (0x10001)
    
    [root@server2 pki]# openssl req -new -key test.key -out test.csr -subj "/CN=test"  // 通过key申请一个证书请求test.csr
    
    [root@server2 pki]# openssl  x509 -req -in test.csr -CA ca.crt -CAkey ca.key  -CAcreateserial -out test.crt -days 365 # 通过证书请求申请一个证书
    Signature ok
    subject=/CN=test
    Getting CA Private Key
    
    [root@server2 pki]# openssl x509 -in test.crt -text -noout  // 查看证书的输出
    
    [root@server2 pki]# ll test.*
    -rw-r--r-- 1 root root  973 May  7 17:14 test.crt
    -rw-r--r-- 1 root root  883 May  7 17:13 test.csr
    -rw-r--r-- 1 root root 1675 May  7 17:12 test.key

[kubeadm@server2 auth]$ kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true // 将证书注入到kubernetes中
    User "test" set.
    
    [kubeadm@server2 auth]$ kubectl  config view     //查看配置
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: DATA+OMITTED
        server: https://172.25.60.2:6443
      name: kubernetes
    contexts:
    - context:
        cluster: kubernetes
        user: kubernetes-admin
      name: kubernetes-admin@kubernetes
    current-context: kubernetes-admin@kubernetes
    kind: Config
    preferences: { }
    users:
    - name: kubernetes-admin    //管理员账户
      user:
        client-certificate-data: REDACTED
        client-key-data: REDACTED
    - name: test  // 除了原来的admin，会加入test用户
      user:
        client-certificate-data: REDACTED
        client-key-data: REDACTED

[kubeadm@server2 auth]$ kubectl config set-context test@kubernetes --cluster=kubernetes --user=test // 让test可以登陆到kubernetes集群
    Context "test@kubernetes" created.
    
    [kubeadm@server2 auth]$ kubectl config use-context test@kubernetes  // 切换为test用户
    Switched to context "test@kubernetes".

此时用户通过认证，但还没有权限操作集群资源，需要继续添加授权。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 6]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 7]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 8]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 9]

# 3. 授权 Authorization #

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

### 3.1RBAC基于角色访问控制授权 ###

**RBAC**：基于角色访问控制授权。

允许管理员通过k8s API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。  
RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即  
RBAC包括四种类型：`Role`,`ClusterRole`,`RoleBinding`,`ClusterRoleBinding`  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 10]RBAC的三个基本概念：

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

Role 和 ClusterRole:

*  Role是一系列的权限的集合，Role只能授予`单个namespace` 中资源的访问权限。
 *  ClusterRole 跟 Role 类似，但是可以`在集群中全局使用`。

注意切换回`kubernetes-admin@kubernetes`

[kubeadm@server1 auth]$ kubectl config use-context kubernetes-admin@kubernetes // 切回admin
    Switched to context "kubernetes-admin@kubernetes".

[kubeadm@server1 auth]$ cat role.yaml   // 创建myrole角色
    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: default
      name: myrole
    rules:
    - apiGroups: [""]
      resources: ["pods"]     //可以操作的资源
      verbs: ["get","watch","list","create","update","patch","delete"]   //操作权限

[kubeadm@server1 auth]$ kubectl apply -f role.yaml 
    role.rbac.authorization.k8s.io/myrole created
    
    [kubeadm@server1 auth]$ kubectl get role
    NAME                                    CREATED AT
    leader-locking-nfs-client-provisioner   2020-05-04T00:37:23Z
    myrole                                  2020-05-07T09:42:20Z  //刚刚创建的角色

### 3.2 RoleBinding角色绑定 ###

**RoleBinding**和**ClusterRoleBinding**：

*  RoleBinding 是将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users，groups，service accounts)，并引用该Role。
 *  RoleBinding 是对某个namespace 内授权，ClusterRoleBinding适用在集群范围内使用。

[kubeadm@server1 auth]$ cat rolebind.yaml    // 给test绑定myrole
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: test-read-pods
      namespace: default
    subjects:                          //绑定用户 test
    - kind: User
      name: test
      apiGroup: rbac.authorization.k8s.io
    roleRef:                   //用户test 绑定角色 myrole
      kind: Role
      name: myrole
      apiGroup: rbac.authorization.k8s.io

test只对pod有权限：

[kubeadm@server1 auth]$ kubectl apply -f rolebind.yaml 
    rolebinding.rbac.authorization.k8s.io/test-read-pods created
    
    [kubeadm@server1 auth]$ kubectl config use-context test@kubernetes // 切换test用户
    Switched to context "test@kubernetes".
    [kubeadm@server1 auth]$ kubectl get pod // test用户拥有了的pod的get权限
    NAME                                      READY   STATUS    RESTARTS   AGE
    nfs-client-provisioner-55d87b5996-8clxq   1/1     Running   1          3d9h
    web-server-54dd87666-284q9                1/1     Running   0          5h23m
    web-server-54dd87666-nqd5p                1/1     Running   0          5h23m
    web-server-54dd87666-xkshd                1/1     Running   0          5h23m

[kubeadm@server1 auth]$ kubectl get sa // 因为没有对test进行sa的授权所以无法查看sa
    Error from server (Forbidden): serviceaccounts is forbidden: User "test" cannot list resource "serviceaccounts" in API group "" in the namespace "default"
    
    [kubeadm@server1 auth]$ kubectl config use-context kubernetes-admin@kubernetes // 切回admin用户
    Switched to context "kubernetes-admin@kubernetes".

上面的角色只针对 default namespaces

### 3.3ClusterRoleBinding集群角色绑定 ###

**创建集群角色：**

[kubeadm@server1 auth]$vim clusterRole.yaml     // 集群角色创建
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: myclusterrole
    rules:
    - apiGroups: [""]
      resources: ["pods"]       //pod资源
      verbs: ["get","watch","list","create","update","delete"]   //操作权限
    - apiGroups: ["extensions","apps"]
      resources: ["deployments"]       //deploments资源
      verbs: ["get","watch","list","create","update","patch","delete"]  //操作权限
    
    [kubeadm@server1 auth]$ kubectl apply -f clusterrole.yaml 
    clusterrole.rbac.authorization.k8s.io/myclusterrole created

**创建绑定：**  
（角色绑定类型）

[kubeadm@server1 auth]$ vim cluasterrolebind.yaml
    kind: RoleBinding          //角色绑定类型
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: rolebind-myclusterrole
      namespace: default    //只能操作 default 命名空间
    subjects:
    - kind: User
      name: test        //将用户test 与集群角色myclusterrole 绑定
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: myclusterrole
      apiGroup: rbac.authorization.k8s.io

只会有设定的权限：

[kubeadm@server1 ~]$ kubectl apply -f clusterrole.yaml 
    clusterrole.rbac.authorization.k8s.io/myclusterrole created
    [kubeadm@server1 ~]$ vim clusterrolebind.yaml
    [kubeadm@server1 ~]$ kubectl apply -f clusterrolebind.yaml 
    rolebinding.rbac.authorization.k8s.io/rolebind-myclusterrole created
    [kubeadm@server1 ~]$ kubectl config use-context test@kubernetes  //切换到test用户
    Switched to context "test@kubernetes".
    [kubeadm@server1 ~]$ kubectl get deployments.apps 
    No resources found in default namespace.
    [kubeadm@server1 ~]$ kubectl get svc
    Error from server (Forbidden): services is forbidden: User "test" cannot list resource "services" in API group "" in the namespace "default"
    [kubeadm@server1 ~]$

**（集群角色绑定类型）**

[kubeadm@server2 auth]$ vim clusterrolebind.yaml // 创建集群角色绑定
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding     //集群角色绑定
    metadata:
      name: clusterrolebinding-myclusterrole   //没有设定命名空间
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: myclusterrole       //集群角色
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: test                //用户test 绑定集群角色 myclusterrole
    
    [kubeadm@server2 auth]$ kubectl apply -f clusterrolebind.yaml 
    clusterrolebinding.rbac.authorization.k8s.io/clusterrolebinding-myclusterrole created

[kubeadm@server2 auth]$ kubectl config use-context test@kubernetes  //切换到test用户
    Switched to context "test@kubernetes".
    
    [kubeadm@server2 auth]$ kubectl -n kube-system get pod
    NAME                              READY   STATUS    RESTARTS   AGE
    coredns-7b8f97b6db-5g4hh          1/1     Running   11         19d
    coredns-7b8f97b6db-jxccd          1/1     Running   11         19d
    etcd-server2                      1/1     Running   26         19d
    kube-apiserver-server2            1/1     Running   49         19d
    kube-controller-manager-server2   1/1     Running   152        19d
    kube-flannel-ds-amd64-6cglm       1/1     Running   21         19d
    kube-flannel-ds-amd64-957jx       1/1     Running   25         19d
    kube-flannel-ds-amd64-gknfj       1/1     Running   24         19d
    kube-proxy-24qlb                  1/1     Running   16         17d
    kube-proxy-cqqk2                  1/1     Running   14         17d
    kube-proxy-l97j8                  1/1     Running   14         17d
    kube-scheduler-server2            1/1     Running   117        19d

因为没有设定特定的namespace  
所以test对pod 和 deployments的所有namespaces都有权限  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 11]

# 4. 准入控制 Admission Control #

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

# 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” 的服务账户。

# 6. kubernetes的用户组 #

Kubernetes 还拥有“用户组”（Group）的概念：  
ServiceAccount对应内置“用户”的名字是：

system:serviceaccount:<ServiceAccount名字 >

而用户组所对应的内置名字是：

system:serviceaccounts:<Namespace名字 >

示例1：表示mynamespace中的所有ServiceAccount

subjects:
    - kind: Group
      name: system:serviceaccounts:mynamespace
      apiGroup: rbac.authorization.k8s.io

示例2：表示整个系统中的所有ServiceAccount

subjects:
     - kind: Group
      name: system:serviceaccounts
      apiGroup: rbac.authorization.k8s.io

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

*  cluster-amdin
 *  admin
 *  edit
 *  view

内置的集群角色：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 12]

[kubeadm@server1 auth]$ kubectl describe clusterrole cluster-admin
    Name:         cluster-admin             // 权限最大
    Labels:       kubernetes.io/bootstrapping=rbac-defaults
    Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
    PolicyRule:
      Resources  Non-Resource URLs  Resource Names  Verbs
      ---------  -----------------  --------------  -----
      *.*        []                 []              [*]
                 [*]                []              [*]

示例：(最佳实践)

kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: readonly-default
    subjects:
    - kind: ServiceAccount
      name: default
      namespace: default
    roleRef:
      kind: ClusterRole
      name: view        // 集群角色：view ----最小权限
      apiGroup: rbac.authorization.k8s.io

[https_kubernetes.io_zh_docs_reference_access-authn-authz_controlling-access]: https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200524174824208.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/202005241752221.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200524180511278.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200524181248781.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[Link 1]: https://blog.csdn.net/weixin_43936969/article/details/106198687#46_kubernetesiodockerconfigjsondocker_registry_333
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200524182442420.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200524182757416.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/2020052418340994.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20200524183416467.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20200524183421460.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20200524183428230.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20200524183849870.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/20200524190707864.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 12]: https://img-blog.csdnimg.cn/2020052419211937.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70