Kubernetes - 认证与授权 - 《Linux》

1.访问控制概述
- 1.1 用户账户与用户组
- 1.2 认证、授权与准入控制基础
2.服务账户管理与应用
3.Kubernetes中的SSL/TLS认证
- 3.1 客户端配置文件kubeconfig
- 3.2 创建自定义用户
  - 3.2.1 为目标用户账号kube-user1创建私钥及证书文件，保存于/etc/kubernetes/pki目录中
  - 3.2.2 以默认的管理员kubernetes-admin@kubernetes为新建的kube-user1设定kube config配置文件
4.基于角色的访问控制：RBAC
小结

1.访问控制概述

API Server作为Kubernetes集群系统的网关，是访问及管理资源对象的唯一入口，余下所有需要访问集群资源的组件，包括kube-controller-manager、 kube-scheduler、kubelet和kube-proxy等集群基础组件、CoreDNS等集群的附加组件以及此前使用的kubectl命令等都要经由此网关进行集群访问和管理。这些客户端均要经由API Server访问或改变集群状态并完成数据存储，并由它对每一次的访问请求进行合法性检验，包括用户身份鉴别、操作权限验证以及操作是否符合全局规范的约束等。所有检查均正常完成且对象配置信息合法性检验无误之后才能访问或存人数据于后端存储系统etcd中。

1.1 用户账户与用户组

客户端访问API服务的途径通常有三种：kubectl、客户端库或者直接使用REST接口进行请求，而可以执行此类请求的主体也被Kubernetes分为两类：现实中的“人”和Pod对象，它们的用户身份分别对应于常规用户(UserAccount)和服务账号(ServiceAccount)。

User Account: 一般是指由独立于k8s之外的其他服务管理的用户账号，例如由管理员分发的密钥、Keystone一类的用户存储、甚至是包含由用户名和密码列表的文件等。
Service Account: 是指由k8s API管理的账号，用于为Pod之中的服务进程在访问k8s API时提供身份标识(identity)。Service Account通常要绑定于特定的名称空间，它们由API Server创建，或者通过API调用手动创建，附带着一组存储为Secret的用于访问API Server的凭据。

User Account通常用于复杂的业务逻辑管控，它作用于系统全局，故其名称必须全局唯一。相比较来说，Service Account隶属于名称空间，仅用于实现某些特定的操作任务，因此要轻量得多。这两类账号都可以隶属于一个或多个用户组。用户组只是用户账号的逻辑集合，它本身并没有操作权限，但附加于组上的权限可由其内部的所有用户继承，以实现高效的授权管理机制。

Kubernetes有着以下几个内建的用于特殊目的的组：

system:unauthenticated: 未能通过任何一个授权插件检验的账号，即未通过认证测试的用户所属的组；
system:authenticated: 认证成功后的用户自动加入的一个组，用于快捷引用所有正常通过认证的用户账号；
system:serviceaccounts: 当前系统上的所有Service Account对象；
system:serviceaccounts:: 特定名称空间内所有的Service Account对象；

API 请求要么与普通用户或服务账户进行绑定，要么被视为匿名请求。这意味着群集内部或外部的每个进程，包括由人类用户使用的kubectl，到节点上的kubelet，再到控制平面的成员组件，必须在向API服务器发出请求时进行身份验证，否则即被视为匿名用户。

1.2 认证、授权与准入控制基础

API Server处理请求的过程中，认证插件负责鉴定用户身份，授权插件用于操作权限许可鉴别，而准入控制则用于在资源对象的创建、删除、更新或连接(proxy)操作时实现更精细的许可检查；

Kubernetes使用身份验证插件对API请求进行身份验证，支持的认证方式包括客户端证书、承载令牌(bearer tokens)、身份验证代理(authenticating proxy)或HTTP basic认证等。

API Server接收到访问请求时，它将调用认证插件尝试将以下属性与访问请求相关联:

Username: 用户名，如kubernetes-admin等；
UID：用户的数字标签符，用于确保用户身份的唯一性；
Groups：用户所属的组，用于权限指派和继承；
Extra：键值数据类型的字符串，用于提供认证时需要用到的额外信息；

API Server 支持以下几种具体的认证方式，其中所有的令牌认证机制通常被统称为承载令牌认证：

X509客户端证书认证：客户端在请求报文中携带X509格式的数字证书用于认证，认证通过后，证书中的主体标识(Subject)将被识别为用户标识，其中的CN (Common Name)字段是用户名，O (Organization)是用户所属的组，如“/CN=iIinux/O=opmasters/O=admin”中，用户名为ilinux，其属于opmasters和admin两个组；
静态令牌文件(Static Token File): 即保存着令牌信息的文件，由kube-apiserver的命令行选项一token-auth-file加载，且服务器启动后不可更改; HTTP客户端也能使用承载令牌进行身份验证，将令牌进行编码后，通过请求报文中的Authorization首部承载传递给API Server即可；
引导命牌(Bootstrap Tokens): 一种动态管理承载令牌进行身份认证的方式，常用于简化新建K8s集群的节点认证过程，—experimental-bootstrap-token-auth 选项启用；使用kubeadm join命令将节点加入kubeadm初始化的集群时使用的即是这种认证方式；
静态密码文件：用户名和密码等令牌以明文格式存储的csv格式文件，由kube apiserver使用—basic-auth-file选项进行加载;
服务账户令牌：由kube-apisever自动启用，并可使用可选选项加载—service-account-key-file验证承载令牌的密钥，省略时将使用kube-apiserver自己的证书匹配的私钥文件;
匿名请求：未被任何验证机制明确拒绝的用户即为匿名用户，其会被自动标识为用户名system:anonymous，并隶属于system:unauthenticated用户组；在API Server启用了除AlwaysAllow以外的认证机制时，匿名用户处于启用状态，不过，管理员可通—anonymous-auth=false选项将其禁用。

API Server主要支持使用四类内建的授权插件来定义用户的操作权限：

Node：基于Pod资源的目标调度节点来实现的对kubelet的访问控制；
ABAC：attribute-based access control，基于属性的访问控制；
RBAC：role-based access control，基于角色的访问控制；
Webhook: 基于HTTP回调机制通过外部REST服务检查确认用户授权的访问控制；

准入控制器 (Admission Controller)则用于在客户端请求经过身份验证和授权检查之后，但在对象持久化存储etcd之前拦截请求，用于实现在资源的创建、更新和删除操作期间强制执行对象的语义验证等功能，读取资源信息的操作请求不会经由准入控制器的检查。

2.服务账户管理与应用

服务账户就是用于让Pod对象内的容器进程访问其他服务时提供身份认证信息的账户。一个Service Account资源一般由用户名及相关的Secret对象组成。

2.1 Service Account自动化

此前创建的每个Pod资源都自动关联了一个存储卷，并由其容器挂载至/var/run/secrets/kubernetes.io/serviceaccount目录。

挂载点目录中通常存在三个文件: ca.crt、namespace和token，其中，token文件保存了Service Account的认证token，容器中的进程使用它向API Server发起连接请求，进而由认证插件完成用户认证并将用户名传递给授权插件；

每个Pod对象都只有一个服务账户，若创建Pod资源时未予以明确指定，则名为ServiceAccount的准入控制器会为其自动附加当前名称空间中默认的服务账户，其名称通常为default。

# kubectl describe serviceaccounts default
Name:                default
Namespace:           default
...
Mountable secrets:   default-token-rhlmd
Tokens:              default-token-rhlmd
...

Kubernetes系统通过三个独立的组件间的相互协作来实现服务账户的自动化，三个组件具体为Service Account准入控制器、令牌控制器(token controller)和 Service Account账户控制器:

Service Account注入控制器：负责为名称空间管理相应的资源，并确保每个名称空间中都存在一个名为default的SA对象：
- 若Pod没有明确定义使用的ServiceAccount对象，则将其设置为“default”；
- 确保Pod明确引用的ServiceAccount已存在，否则请求将被拒绝；
- 若Pod对象中不包含ImagePullSecerts，则把ServiceAccount的ImagePullSecrets添加于其上;
- 为带有访问API的令牌的Pod添加一个存储卷;
- 为Pod对象中的每个容器添加一个volumeMounts，挂载至/var/run/secrets/kubemetes.io/serviceaccount;
令牌控制器(token controller)是controller-manager的子组件，工作于异步模式：
- 监控Service Account的创建操作，并为其添加用于访问API的Secret对象；
- 监控Service Account的删除操作，并删除其相关的所有Service Account令牌密钥；
- 监控Secret对象的添加操作，确保其引用的Service Account己存在，并在必要时为Secret对象添加认证令牌；
- 监控Secret对象的删除操作，以确保删除每个Service Account中对此Secret的引用；

2.2 创建服务账户

Service Account(简称sa)是Kubernetes API上的一种资源类型，它隶属于名称空间，用于让Pod对象内部的应用程序在与API Server通信时完成身份认证。事实上，每个名称空间都有一个名为default的默认资源对象，其可用于让Pod对象有权限读取同一名称空间中的其他资源对象的元数据信息。需要赋予Pod对象更多操作权限时，则应该由用户按需创建自定义的SA资源。

每个Pod对象均可附加其所属名称空间中的一个SA资源，且只能附加一个。不过，一个SA资源可由其所属名称空间中的多个Pod对象共享使用。创建Pod资源时，可使用spec.serviceAccountName指定要使用的SA资源，或省略此字段由其自动附加当前名称空间中的默认的SA(default)。

可使用资源配置文件创建SA资源，也可直接使用kubectl create servic-eaccount命令进行创建，提供认证令牌的Secret对象会由命令自动创建完成。下面的配置清单是一个SA资源示例，它仅指定了创建名为sa-demo的服务账户，其余的信息则交由系统自动生成:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-damo
  namespace: default

创建Pod对象时，可为Pod对象指定使用自定义的服务账户，从而实现自主控制Pod对象资源的访问权限。Pod向API Server发出请求时，其携带的认证令牌在通过认证后将由授权插件来判定相关的SA是否有权限访问所请求的资源。K8s支持多种授权插件，由管理员负责选定及配置，RBAC是目前较为主流的选择。

2.3 调用imagePullSecret资源对象

SA资源还可以基于spec.imagePullSecret字段附带一个由下载镜像专用的Secret资源组成的列表，用于在进行容器创建时，从某私有镜像仓库下载镜像文件之前进行服务认证。

apiVersion: v1
kind: ServiceAccount
medatadata:
  name: image-download-sa
imagePullSecrets:
- name: local-harbor-secret

其中，local-harbor-secret是docker-registry类型的Secret对象，由用户提前手动创建，它可以通过键值数据提供docker仓库服务器的地址、接入服务器的用户名、密码及用户的电子邮件等信息。认证通过后，引用了此ServiceAccount的Pod资源即可从指定的镜像仓库中下载由image字段指定的镜像文件。

3.Kubernetes中的SSL/TLS认证

构建安全基础通信环境的Kubernetes集群时，需要用到TLS及数字证书的通信场景有很多种。API Server是整个Kubernetes集群的通信网关，controller-manager、scheduler、kubelet及kube-proxy等均需要经由API Server与etcd通信完成资源状态信息的获取及更新等。同样出于安全通信的目的，master的各组件(API Server、controller-manager和scheduler)需要基于SSL/TLS向外提供服务，而且与集群内部组件间进行通信时(主要是各节点上的kubelet和kube-proxy)还需要进行双向身份验证。

K8s集群种各资源的状态信息，包括Secret对象种的敏感信息等均以明文方式存储于etcd中，因此，etcd集群内各节点间的通信，已经各节点与其客户端(主要是API Server)之间的通信都应该以加密的方式进行，并需进行身份验证。

etcd集群内对等节点通信：etcd集群内各节点间集群事务通信，默认监听与TCP的2380端口，基于SSL/TLS通信时需要peer类型的数字证书，可实现节点间的身份认证及通信安全，这些证书需要由一个专用CA进行管理；
etcd服务器与客户端通信：etcd的REST API服务，默认监听于TCP的2379端口，用于接收并响应客户端请求，基于SSL/TLS通信，支持服务端认证和双向认证，而且要使用一个专用CA来管理此类证书；kube-apiserver就是etcd服务的主要客户端；

API Server与其客户端之间采用HTTPS通信可兼顾实现通信与认证的功能，它们之间通信的证书可由同一个CA进行管理，其客户端大体分为三类：

控制平面的kube-scheduler和kube-controller-manager
工作节点组件kubelet和kube-proxy: 初次接入集群时，kubelet可自动生成私钥和证书签署请求，并由Master为其自动进行证书签名和颁发；
kubelet及其他形式的客户端，如Pod对象等。

3.1 客户端配置文件kubeconfig

包括kubectl、kubelet和kube-controller-manager等在内的API Server的各类客户端都可以使用kubeconfig配置文件提供接入多个集群的相关配置信息，包括各API Server的URL及认证信息等，而且能够设置成不同的上下文环境，并在各环境之间快速切换。

使用kubeadm初始集群后生成的/etc/kubemetes/admin.conf文件即为kubeconfig格式的配置文件，其由kubeadm init命令自动生成，可由kubectl加载(默认路径为 $HOME/.kube/config)后用于接入服务器。kubectl config view命令能够显示当前正在使用的配置文件，下面的命令结果打印了文件中配置的集群列表、用户列表、上下文列表以及当前使用的上下文(current-context)等:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://172.17.20.29: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

clusters: 集群列表，包含访问API Server的URL和所属集群的名称等；
users：用户列表，包含访问API Server时的用户名和认证信息；
contexts: kubelet的可用上下文列表，由用户列表中的某特定用户名称和集群列表中的某特定集群名称组合而成；
current-context: kubelet当前使用的上下文名称，即上下文列表中的某个特定项；

3.2 创建自定义用户

管理员还可以创建其它基于SSL/TLS认证的自定义用户账号，以授予非管理员级的集群资源使用权限，其配置过程由两部分组成：一是为用户创建专用私钥及证书文件，二是将其配置于某kubeconfig文件中。下面给出其具体的实现过程，并借此创建将一个测试用户kube-user1用于后文中的授权测试：

3.2.1 为目标用户账号kube-user1创建私钥及证书文件，保存于/etc/kubernetes/pki目录中

生成私钥文件，注意其权限应该为600以阻止其他用户随意获取，这里在Master节点上以root用户进行操作，并将文件放置于/etc/kubernetes/pki专用目录中:

# cd /etc/kubernetes/pki
# (umask 077; openssl genrsa -out kube-user1.key 2048)

创建证书签署请求，-subj选项中的CN的值将被kubeconfig作为用户名使用，O的值将被识别为用户组：

# openssl req -new -key kube-user1.key -out kube-user1.csr -subj "/CN=kube-user1/O=kubeusers"

基于kubeadm安装k8s集群时生成的CA签署证书，这里设置其有效时长为3650天：

# openssl x509 -req -in kube-userl.csr -CA ca.crt -CAkey ca.key CAcreateserial -out kube-userl. crt -days 3650

3.2.2 以默认的管理员kubernetes-admin@kubernetes为新建的kube-user1设定kube config配置文件

配置集群信息，包括集群名称、APIServerURL和CA证书，若集群信息已然存在，则可省略此步，另外，提供的新配置不能与现有配置中的集群名称相同，否则将覆盖它们:

# kubectl config set-cluster kubernetes --embed-certs=true \
--certificate-authority=/etc/kubernetes/pki/ca.crt -server="https://172.16.0.70:6443"

配置客户端证书及密钥，用户名信息会通过命令从证书Subject的CN值中自动提取，例如前面创建csr时使用的”CN=kube-user1”，而组名则来自于“O=kubeusers”的定义:

# kubectl config set-credentials kube-user1 --embed-certs=true \
--client-certificate=/etc/kubernetes/pki/kube-user1.crt \
--client-key=/etc/kubernetes/pki/kube-user1.key

配置context，用来组合cluster和credentials，即访问的集群的上下文。如果为管理多个集群而设置了多个环境，则可以使用use-context来进行切换：

# kubectl config set context kube-user1@kubernetes --cluster=kubernetes --user=kube-user1

指定要使用的上下文，切换为以kube-user1访问集群：

# kubectl config use-context kube-user1@kubernetes

若要切至管理员账号，则可使用：

# kubectl config use-context kubernetes-admin@kubernetes

4.基于角色的访问控制：RBAC

RBAC(Role-Based Access Control，基于角色的访问控制)是一种新型、灵活且使用广泛的访问控制机制，它将权限授予“角色”(role)之上，这一点有别于传统访问控制机制中将权限直接赋予使用者的方式。

RBAC的基于“角色”(role)这一核心组件实现了权限指派，具体实现中，它为账号赋予一到多个角色从而让其具有角色之上的权限，其中的账号可以是用户账号、用户组、服务账号及其相关的组等，而同时关联至多个角色的账号所拥有的权限是多个角色之上的权限集合。

4.1 RBAC授权插件

RBAC是一种操作授权机制，用于界定“谁”(subject)能够或不能够“操作”(verb)哪个或哪类“对象”(object)。动作的发出者即“主体”，通常以“账号”为载体，它既可以是常规用户(User Account)，也可以是服务账号(Service Account)。“操作”(verb)用于表明要执行的具体操作，包括创建、删除、修改和查看等，对应于kubectl来说，它通常由create、apply、delete、update、patch、edit和get等子命令来给出。而“客体”则是指操作施加于的目标实体，对Kubemetes API来说主要是指各类的资源、对象以及非资源型URL。

现对于ABAC和Webhook等授权机制来说，RBAC具有如下优势：

对集群中的资源和非资源型URL的权限实现了完整覆盖；
整个RBAC完全由少数几个API对象实现，而且同其他API对象一样可以用kubectl或API调用进行操作；
支持权限的运行时调整，无须重新启动API Server；

RBAC授权插件支持Role和ClusterRole两类角色，其中Role作用于名称空间级别，用于定义名称空间内的资源权限集合，而ClusterRole则用于组织集群级别的资源权限集合，它们都是标准的API资源类型。一般来说，ClusterRole的许可授权作用于整个集群，因此常用于控制Role无法生效的资源类型，这包括集群级别的资源(如Nodes)、非资源类型的端点(如/healthz)和作用于所有名称空间的资源(例如，跨名称空间获取任何资源的权限)。

对这两类角色进行赋权时，需要用到RoleBinding和ClusterRoleBinding这两种资源类型。RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上，它隶属于且仅能作用于一个名称空间。绑定时，可以引用同一名称中的Role，也可以引用集群级别的ClusterRole。而ClusterRoleBinding则把ClusterRole中定义的许可权限绑定在一个或一组用户之上，它仅可以引用集群级别的ClusterRole。

一个名称空间中可以包含多个Role和RoleBinding对象，类似地，集群级别也可以同时存在多个ClusterRole和ClusterRoleBinding对象。而一个账户也可经由RoleBinding或ClusterRoleBinding关联至多个角色，从而具有多重许可授权。

4.2 Role和RoleBinding

Role仅是一组许可(permission)权限的集合，它描述了对哪些资源可执行何种操作，资源配置清单中使用rules字段嵌套授权规则。下面是一个定义在testing名称空间中的Role对象的配置清单示例，它设定了读取、列出及监视Pod和Service资源的许可权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: testing
  name: pods-reader
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list","watch"]

类似上面的Role对象中的rules也成为PolicyRule，用于定义策略规则，不过它不包含规则应用的目标，其可以内嵌的字段包含：

apiGroups: 包含了资源的API组的名称，支持列表格式指定的多个组，空(“”)表示核心组；
resourceNames: 规则应用的目标资源名称列表，可选，缺省时意味着指定资源类型下的所有资源；
resources：规则应用的目标资源类型组成的列表，如pods、deployments、daemonsets等，ResourceAll表示所有资源；
verbs：可应用至此规则匹配到的所有资源类型的操作列表，可用选项有get、list、create、update、patch、watch、proxy、redirect、delete和deletecollection；必选字段；

除了编写配置清单创建Role资源之外，还可以直接使用kubectl create role命令进行快速创建，例如：

# kubectl create role services-admin --verb="*" --resource="services,services/*" -n testing

绝大多数资源均可通过其资源类型的名称引用，如”pods”或”services”等，这些名字与它们在API endpoint中的形式相同。不过，有些资源类型还支持子资源( subresource)，例如Pod对象的/log，Node对象的/status等，它们的URL格式通常形如：GET /api/v1/namespaces/{namespace}/pods/{name}/log

RoleBinding用于将Role中定义的权限赋予一个或一组用户，它由一组主体，以及一个要引用来赋予这组主体的Role或ClusterRole组成。RoleBinding仅能够引用同一名称空间中的Role对象完成授权，例如，下面配置清单中的RoleBinding于testing名称空间中将pods-reader角色赋给了用户kube-user1，从而使得kube-user1拥了此角色之上的所有许可授权:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: resources-reader
  namespace: testing
subjects:
- kind: User
  name: kube-user1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pods-reader
  apiGroup: rbac.authorization.k8s.io

将此RoleBinding资源应用到集群中，kube-user1用户便有了读取testing名称空间中pods资源的权限。将kubectl的配置上下文切换至kube-user1用户，分别对pods 和services资源发起访问请求测试，由下面的命令结果可以看出，它能够请求读取pods资源，但对其他任何资源的任何操作请求都将被拒绝：

# kubectl config use-context kube-user1@kuberntes
Switched to context "kube-userl@kubernetes”
# kubectl get pods -n testing
No resources found
# kubectl get services -n testing
Error from server (Forb工dden): services is forbidden: User "kube-user1 ” cannot list services in the namespace "testing”

RoleBinding的配置中主要包含两个嵌套的字段subjects和roleRef，其中，subjects的值是一个对象列表，用于给出要绑定的主体，而roleRef的值是单个对象，用于指定要绑定的Role或ClusterRole资源。subjects字段的可嵌套宇段具体如下：

apiGroup: 要引用的主机所属的API群组，对于ServiceAccount类的主体来说默认为””，而User和Group类主体的默认值为”rbac.authorization.k8s.io”；
kind: 要引用的资源对象(主体)所属的类别，可用值为User、Group和ServiceAccount，必选；
name: 要引用的主体的名称，必选；
namespace: 引用的主机所属的名称空间，对于非名称空间类型的主体，如User和Group，其值必须为空，否则授权插件将返回错误信息；

roleRef的可嵌套字段：

apiGroup: 引用的资源(Role或ClusterRole)所属的API群组，必选；
kind：引用的资源所属的类别，可用值为Role或ClusterRole，必选；
name：引用的资源的名称；

4.3 ClusterRole和ClusterRoleBinding

集群级别的角色资源ClusterRole资源除了能够管理与Role资源一样的许可权限之外，还可以用于集群级组件的授权，配置方式及其在rules宇段中可内嵌的字段也与Role资源类似。下面的配置清单示例中定义了ClusterRole资源nodes-reader，它拥有访问集群的节点信息的权限：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nodes-reader
rules:
- apiGroup: [""]
  resources: ["nodes"]
  verbs: ["get","watch","list"]

RoleBinding也能够将主体绑定至ClusterRole资源之上，但仅能赋予用户访问Role Binding资源本身所在的名称空间之内可由ClusterRole赋予的权限，例如，在ClusterRole具有访问所有名称空间的ConfigMap资源权限时，通过testing名称空间的RoleBinding将其绑定至kube-user1用户，则kube-user1用户就具有了访问testing名称空间中的ConfigMap资源的权限，但不能访问其他名称空间中的ConfigMap资源。不过，若借助ClusterRoleBinding进行绑定，则kube-user1就具有了所有相关名称空间中的资源的访问权限。

集群级别的资源nodes、persistentvolumes等资源，以及非资源型的URL不属于名称空间级别，故此通过RoleBinding绑定至用户时无法完成访问授权。事实上，所有的非名称空间级别的资源都无法通过RoleBinding绑定至用户并赋予用户相关的权限，这些是属于ClusterRoleBinding的功能。

另外，除了名称空间及集群级别的资源之外，Kubernetes还有着/api、/apis、/healthz、/swaggerapi和/version等非资源型URL，对这些URL的访问也必须事先获得相关的权限。同集群级别的资源一样，它们也只能定义在ClusterRole中，且需要基于ClusterRoleBinding进行授权。不过，对此类资源的读取权限已经由系统默认的名称同为system:discovery的ClusterRole和ClusterRoleBinding两个资源自动设定。下面的命令显示了system:discovery ClusterRole的相关信息：

# kubectl get clusterrole system:discovery -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:discovery
  ...
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /livez
  - /openapi
  - /openapi/*
  - /readyz
  - /version
  - /version/
  verbs:
  - get

# kubectl get clusterrolebindings.rbac.authorization.k8s.io system:discovery -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:discovery
  ...
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

4.4 面向用户的内建ClusterRole

API Server内建了一组默认的ClusterRole和ClusterRoleBinding以预留系统使用，其中大多数都以”system:”为前缀。另外还有一些非以“system:”为前缀的默认的Role资源，它们是为面向用户的需求而设计的，包括超级用户角色(cluster-admin)、用于授权集群级别权限的ClusterRoleBinding(cluster-status)以及授予特定名称空间级别权限的RoleBinding(admin、edit和view)。

为Kubemetes集群额外自定义超级管理员的方法至少具有两种：一种是创建用户证书，其Subject中O的值为“system:masters”，另一种是创建ClusterRoleBinding将用户绑定至cluster-admin之上。

小结

Kubernetes系统的认证、授权及准入控制插件的工作流程；
Service Account资源及其应用方式；
HTTPS客户端证书认证及其在kubectl和tls bootstrap中的应用；
Role及Rolebinding的工作机制及应用方式；
ClusterRole及ClusterRoleBinding的工作机制及其应用方式；
借助默认的ClusterRole及ClusterRoleBinding实现集群及名称空间级别权限的快速授予；

认证与授权