kubernetes认证鉴权内容有哪些

本文讲解"kubernetes认证鉴权内容有哪些",希望能够解决相关问题。

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=config

serviceAccount

上面说了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认证鉴权内容有哪些" 就介绍到此。希望多多支持编程教程

下一章:Docker中的网络模式有哪些

本文讲解"Docker中的网络模式有哪些",希望能够解决相关问题。实现原理Docker使用Linux桥接,在宿主机虚拟一个Docker容器网桥(docker0),Docker启动一个容器时会根据Docker网 ...