概要
你有没有想过在执行 kubectl 命令的时候，kube-apiserver 是怎么认证你的身份的？
身份认证过后是怎么鉴别你是否有权限操作所访问的API资源的，如果想通过 API 访问 kube-apiserver 接口，如何通过认证鉴权？
如果一个集群同时要给运维、开发、测试使用，而且各自的资源和操作互不影响应该怎么给用户配置权限？
如果这些问题你都了然于胸，那么你可以跳过本文，否则本文将带你学习 kubernetes 中的认证鉴权规则。
通过本文你将学习到以下知识点：
kubeconfig 文件的结构RBAC 鉴权原理通过 API 访问 kube-apiserver 如何进行鉴权kubeconfig文件的结构
kubectl 作为操作 k8s 的一个客户端工具，只要为 kubectl 提供连接 apiserver 的配置kubeconfig文件，kubectl 可以在任何地方操作该集群，当然，若 kubeconfig 文件中配置多个集群，kubectl 也可以轻松地在多个集群之间切换。下面是kubeconfig文件结构：
apiVersion: v1 clusters: – cluster: certificate-authority-data: xxx server: https://127.0.0.1:6443 name: kubernetes contexts: – context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes users: – name: kubernetes-admin user: client-certificate-data: xxxxx client-key-data: xxxxx current-context: kubernetes-admin@kubernetes kind: Config preferences: {}主要包括：clusters、contexts、users 三部分，这三个单词都是复数形式的，暗示他们是数组结构，也就是可以配置多个，这为多集群（kubectl连接到不同集群）和多用户（同一个集群不同用户）切换提供了便利。
clusters
certificate-authority-data 是集群的CA证书，kubectl 使用该配置对 kube-apiserver 返回的服务端证书做校验，用于客户端校验服务端的证书有效性。这里拓展下，当你在浏览器输入baidu.com时，为了建立安全链接，baidu服务器会返回服务端证书，因为返回的服务端证书是权威机构CA签发的，本地浏览器或操作系统内置了权威机构的CA，所以可以在本地找到CA对返回的服务端做合法性验证，但是一般我们部署的k8s集群使用的都是自签发的证书，在本地是找不到对应的CA证书对kube-apiserver返回的证书，所以需要配置集群的CA。server 表示集群的地址；name 表示集群的名字，该名字在后面的contexts会被用来关联集群信息。
contexts
kubectl 运行时候的上下文信息，cluster（就是上面 clusters 中cluster的名字）和 user 分别表示在当前上下文下使用的是哪个用户连接到哪个集群；name 表示上下文的名字，如果需要切换上下文，可以使用 kubectl config use-context {context name} 进行切换，切换后kubectl就会使用该上下文中定义的用户去访问对应的集群。
users
client-certificate-data 用于 kubectl 和 kube-apiserver 进行双向认证加密的客户端证书，当 kubectl 和 kube-apiserver 进行https连接时，kubectl会把该证书发送给 kube-apiserver ，后续 kubectl 使用私钥 client-key-data 加密数据发送给 kube-apiserver时，kube-apiserver收到数据后使用 client-certificate-data 进行解密获得明文数据。
实际上，在k8s中没有User（用户）概念的，或者说没有User这样的资源对象，kubeconfig文件的中User实际上是管理员给用户签发证书（users字段中的client-certificate-data）的时候使用的csr文件中指定的CN,如：
{ “CN”: “david”, “hosts”: [“david.com”], “key”: { “algo”: “rsa”, “size”: 2048 }, “names”: [ { “C”: “CN”, “ST”: “Beijing”, “L”: “Beijing”, “O”: “k8s”, “OU”: “System” } ] }kubectl在和kube-apiserver建立https连接后，kube-apiserver会取CN字段作为User（k8s本身不维护User信息），进而进行后续的鉴权工作。具体如何为用户签发证书，可以参考该文章，本文不作发散。
给用户签发完证书后，管理员就获得了该用户的证书（client-certificate-data）和私钥（client-key-data），然后就可以给该用户生成kubeconfig文件了，kubectl提供了kubectl config命令就行添加，如下：
# 添加集群信息 kubectl config set-cluster {cluster_name} –certificate-authority=ca.crt –embed-certs=true –server=https://172.11.11.13:6443 –kubeconfig=config # 添加用户信息 kubectl config set-credentials {username} –client-certificate=username.crt –client-key=username.key –embed-certs=true –kubeconfig=config # 添加上下文信息 kubectl config set-context {context_name} –cluster={cluster_name} –user={username} –kubeconfig=configserviceAccount
上面说了kubeconfig文件是给用户在操作kubectl的时候认证使用的，但是如果进程（如集群内的容器）想访问集群资源的话，用这种方式不太方便了，所以 serviceAccount 的概念应运而生，见名思意，服务账号它存在的初衷就是给服务使用而不是给人用的。
当在集群中创建一个 serviceAccount 后，集群会自动在对应的namespace下生成一个secret，内容形式如下：
apiVersion: v1 data: ca.crt: xxx namespace: xxxxx token: xxxxxx kind: Secret metadata: xxxx type: kubernetes.io/service-account-token ca.crt：签发kube-apiserver证书的ca证书，客户端使用该ca去校验kube-apiserver证书。token：该token实际为一个jwt，可以使用jwt.io/查看实际的内容，token中 service-account.name 指定了用户的实际身份，为认证和鉴权提供了信息。namespace：serviceAccount所属的namespace。每一个namespace下面，集群都会创建一个默认的serviceAccount和对应的secret，不过该secret没有操作集群资源的权限。
如果想要在Pod内使用自己创建的sa的secret，可以在deploy中指定sa即可，如：
apiVersion: v1 kind: Deploy metadata: (…) spec: containers: – image: nginx (…) serviceAccountName: {name}这样创建出来的Pod，Pod内的容器目录/var/run/secrets/kubernetes.io/serviceaccount/下便会出现三个文件：
$ ls -al /var/run/secrets/kubernetes.io/serviceaccount/ total 4 drwxrwxrwt 3 root root 140 May 10 2022 . drwxr-xr-x 3 root root 4096 May 10 2022 .. lrwxrwxrwx 1 root root 13 May 10 2022 ca.crt -> ..data/ca.crt lrwxrwxrwx 1 root root 16 May 10 2022 namespace -> ..data/namespace lrwxrwxrwx 1 root root 12 May 10 2022 token -> ..data/token如果想要验证创建的sa对应的secret有没有权限访问集群的资源，可以使用如下命令：
# CACERT也可以不使用，代替的是在curl命令中加上-k选项 CACERT=”xxx” TOKEN=”xxx” namespace=”xxx” APISERVER=”xxxx” curl –cacert ${CACERT} –header “Authorization: Bearer ${TOKEN}” -X GET ${APISERVER}/api/v1/namespaces/${namespace}/pods但是，有了sa后只能让kube-apiserver知道你是谁，并不知道你有没有权限去操作某些资源，简而言之，目前完成的是认证步骤。就好比，进小区需要刷门禁卡，如果你是这个小区的人，那么你就可以进入该小区，但是进入小区后想要进入对应的房间，还需要进一步识别你的身份，如钥匙、指纹、人脸识别等手段。所以，kube-apiserver还需要对请求做进一步的鉴权，才能确定是否放行。那么kubernetes是使用什么方式鉴权的呢？答案就是：RBAC。
RBAC
RBAC（Role-Based Access Control），基于角色的访问控制。角色可以由命名空间（namespace）内的 Role 对象定义，而整个 Kubernetes 集群范围内有效的角色则通过 ClusterRole 对象实现。
Role
Role在k8s里面也是一种资源，表示能对某个命名空间的什么资源做什么操作。一个 Role 对象只能用于授予对某一单一命名空间中资源的访问权限。以下示例描述了 default 命名空间中的一个 Role 对象的定义，用于授予对 pod 的读访问权限：
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: namespace-pod-get rules: – apiGroups: [“”] resources: [“pods”] verbs: [“get”, “watch”, “list”]ClusterRole
ClusterRole 对象可以授予与 Role 对象相同的权限，但由于它们属于集群范围对象， 也可以使用它们授予对以下几种资源的访问权限：
集群范围资源（例如节点，即 node）非资源类型 endpoint（例如”/healthz”）跨所有命名空间的命名空间范围资源（例如 pod，需要运行命令 kubectl get pods –all-namespaces 来查询集群中所有的 pod） kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: # 由于 ClusterRole 是集群范围对象，所以这里不需要定义 “namespace” 字段 name: cluster-pod-get rules: – apiGroups: [“”] resources: [“pods”] verbs: [“get”, “watch”, “list”]Role和ClusterRole都表示能对什么资源做什么操作，也就是权限范围。但是缺少一个主体，即谁有这个权限。单独的Role和ClusterRole存在是没有意义的，必须有一个主体去跟它做绑定才能发挥作用。于是和Role和ClusterRole对应的就有RoleBinding和ClusterRoleBinding。
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: fetch-pods namespace: default subjects: – kind: User name: test apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: namespace-pod-get apiGroup: rbac.authorization.k8s.io subjects: 主体，表示谁要和Role绑定。这里的Kind可以有三个选择，User、ServiceAccount或Group，其中最常用的是前面两种。ServiceAccount: 有没有发现，这里和前面讲的ServiceAccount产生关联了，前面我们说ServiceAccount只能说明你是谁，并没有说明你有什么权限，这里我们做了角色绑定后，那么ServiceAccount的权限也就有了。User: 就是上文提到过的证书请求文件csr中的CN字段指定的值，做了绑定后，也就是User具有相关权限了。Group: 可以是上文提到过的证书请求文件csr中的O字段指定的值或者name为system:开头指定的一些系统保留组，具体可以看官方文档具体有哪些组可以使用。roleRef: 角色引用，表示上述的主体和什么角色做绑定，如果是RoleBinding那么此处的角色Kind就是Role，而ClusterRoleBinding则此处的角色Kind就是ClusterRole；name 表示跟哪个Role绑定。通过角色绑定后，服务账号或者是用户，都具有了Role中指定的集群资源操作权限。
以上就是kubernetes认证鉴权内容浅析的详细内容，更多关于kubernetes认证鉴权的资料请关注其它相关文章！
暂无评论内容