K8S认证、授权与准入控制(RBAC)详解

发布时间:2020-06-06 21:48:15 作者:李永峰Billy
来源:网络 阅读:10573

相关推荐

本文的kubernetes环境:https://blog.51cto.com/billy98/2350660

RBAC官方文档:https://kubernetes.io/docs/reference/access-authn-authz/rbac/


前言

  1. RBAC (Role-Based Access Control,基于角色的访问控制)是一种新型、灵活且使用广泛的访问控制机制,它将权限授予“角色”(role)之上,这一点有别于传统访问控制机制中 将权限直接赋予使用者的方式,简单点来说就是将权限绑定到role中,然后用户和role绑定,这样用户就拥有了和role一样的权限。
  2. 在任何将资源或服务提供给有限使用者的系统上,认证和授权都是两个必不可少的功 能,认证用于身份鉴别,而授权则实现权限分派 。 Kubemetes 以插件化的方式实现了这两种 功能,且分别存在多种可用的插件。 另外,它还支持准入控制机制,用于补充授权机制以实现更精细的访问控制功能 。
  3. API Server 作为 Kubernetes 集群系统的网关,是访问及管理资源对象的唯一人口,所有需要访问集群资源的组件,以及此前使用的 kubectl 命令等都要经由此网关进行集群访问和管理。
  4. RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策,允许管理员通过 Kubernetes API 动态配置策略,要启用RBAC,需要在 apiserver 中添加参数--authorization-mode=RBAC,如果使用的kubeadm安装的集群,都默认开启了RBAC,可以通过查看 Master 节点上 apiserver 的静态Pod定义文件:
    [root@node-01 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml 
    ···
    - --authorization-mode=Node,RBAC
    ···
  5. 如果是二进制的方式搭建的集群,添加这个参数过后,记得要重启 apiserver 服务。

RBAC API资源对象

Kubernetes有一个很基本的特性就是它的所有资源对象都是模型化的 API 对象,允许执行增、删、改、查等操作,比如下面的这下资源:

上面这些资源对象的可能存在的操作有:

用户账户和用户组

Kubernetes 并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息,它们仅仅用于检验用户是否有权限执行其所请求的操作。

客户端访问API服务的途径通常有三种:kubectl、客户端库或者直接使用 REST接口进行请求。

而可以执行此类请求的主体也被 Kubernetes 分为两类:现实中的“人”和 Pod 对象, 它们的用户身份分别对应于常规用户 (User Account )和服务账号 ( Service Account) 。

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

Role和ClusterRole

  1. Role是只作用于命名空间级别的,用于定义命名空间内资源权限集合。
  2. ClusterRole则用于集群级别的资源权限集合,它们都是标准的 API 资源类型 。
  3. 一般来说, ClusterRole 的许可授权作用于整个集群,因此常用于控制 Role 无法生效的资源类型,这包括集群级别的资源(如Nodes)、非资源类型的端点(如/healthz)和作用于所有命名空间的资源(例如跨命名空间获取任何资源的权限)。

RoleBinding和ClusterRoleBinding

  1. RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上,它隶属于且仅能作用于一个命名空间。绑定时,可以引用同一名称中的Role,也可以引用集群级别的 ClusterRole。

  2. ClusterRoleBinding则把ClusterRole中定义的许可权限绑定在一个或一组用户之上,它仅可以引用集群级别的ClusterRole。
  3. Role、RoleBinding、ClusterRole和ClusterRoleBinding 的关系如图 所示 。
    K8S认证、授权与准入控制(RBAC)详解

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

下面我们来创建一个User Account,测试访问某些我们授权的资源:

创建k8s User Account

一、创建证书

  1. 创建user私钥

    [root@node-01 ~]# cd /etc/kubernetes/pki/
    [root@node-01 pki]# (umask 077;openssl genrsa -out billy.key 2048)
    Generating RSA private key, 2048 bit long modulus
    .................................................................................+++
    ..................+++
    e is 65537 (0x10001)
  2. 创建证书签署请求
    O=组织信息,CN=用户名

    [root@node-01 pki]# openssl req -new -key billy.key -out billy.csr -subj "/O=jbt/CN=billy"
  3. 签署证书
    [root@node-01 pki]# openssl  x509 -req -in billy.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out billy.crt -days 365
    Signature ok
    subject=/O=jbt/CN=billy
    Getting CA Private Key

    二、创建配置文件

    创建配置文件主要有以下几个步骤:

    kubectl config set-cluster --kubeconfig=/PATH/TO/SOMEFILE      #集群配置
    kubectl config set-credentials NAME --kubeconfig=/PATH/TO/SOMEFILE #用户配置
    kubectl config set-context    #context配置
    kubectl config use-context    #切换context

创建集群配置

[root@node-01 pki]# kubectl config set-cluster k8s --server=https://10.31.90.200:8443 --certificate-authority=ca.crt --embed-certs=true --kubeconfig=/root/billy.conf
Cluster "k8s" set.

[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []

创建用户配置

[root@node-01 pki]# kubectl config set-credentials billy --client-certificate=billy.crt --client-key=billy.key --embed-certs=true --kubeconfig=/root/billy.conf
User "billy" set.

#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts: []
current-context: ""
kind: Config
preferences: {}
users:
- name: billy
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

创建context配置

[root@node-01 pki]# kubectl config set-context billy@k8s --cluster=k8s --user=billy --kubeconfig=/root/billy.conf
Context "billy@k8s" created.

#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts:
- context:
    cluster: k8s
    user: billy
  name: billy@k8s
current-context: ""
kind: Config
preferences: {}
users:
- name: billy
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

切换context

[root@node-01 pki]# kubectl config use-context billy@k8s --kubeconfig=/root/billy.conf
Switched to context "billy@k8s".

#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts:
- context:
    cluster: k8s
    user: billy
  name: billy@k8s
current-context: billy@k8s
kind: Config
preferences: {}
users:
- name: billy
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

创建系统用户及k8s验证文件

[root@node-01 ~]# useradd billy     #创建什么用户名都可以
[root@node-01 ~]# mkdir /home/billy/.kube
[root@node-01 ~]# cp billy.conf /home/billy/.kube/config
[root@node-01 ~]# chown billy.billy -R /home/billy/.kube/
[root@node-01 ~]# su - billy
[billy@node-01 ~]$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "default"
#默认新用户是没有任何权限的。

创建Role

此role只有pod的get、list、watch权限

[root@node-01 rbac]# cat pods-reader.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pods-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

[root@node-01 rbac]# kubectl apply -f pods-reader.yaml 
role.rbac.authorization.k8s.io/pods-reader created

创建Rolebinding

用户billy和role pods-reader的绑定

[root@node-01 rbac]# cat billy-pods-reader.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: billy-pods-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: billy

[root@node-01 rbac]# kubectl apply -f billy-pods-reader.yaml 
rolebinding.rbac.authorization.k8s.io/billy-pods-reader created

验证结果

如果没有指定命名空间的话,默认就是default命名空间。

[billy@node-01 ~]$ kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
nginx-demo-95bd675d5-66xrm   1/1     Running   0          18d
tomcat-5c5dcbc885-7vr68      1/1     Running   0          18d

[billy@node-01 ~]$ kubectl -n kube-system get pod
Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "kube-system"

所以我们是可以查看查看default命名空间的pod,但是其他空间的pod是无法查看的。

创建ClusterRole

[root@node-01 rbac]# cat cluster-reader.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

[root@node-01 rbac]# kubectl apply -f cluster-reader.yaml 
clusterrole.rbac.authorization.k8s.io/cluster-reader created

创建ClusterRoleBinding

[root@node-01 rbac]# cat billy-read-all-pods.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: billy-read-all-pods
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: billy

[root@node-01 rbac]# kubectl apply -f billy-read-all-pods.yaml 
clusterrolebinding.rbac.authorization.k8s.io/billy-read-all-pods created

验证结果

创建了ClusterRole和ClusterRoleBinding后就可以看到所有命名空间的pod了。

[billy@node-01 ~]$ kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
nginx-demo-95bd675d5-66xrm   1/1     Running   0          18d
tomcat-5c5dcbc885-7vr68      1/1     Running   0          18d

[billy@node-01 ~]$ kubectl -n kube-system get pod
NAME                                        READY   STATUS    RESTARTS   AGE
canal-gd4qn                                 2/2     Running   0          21d
cert-manager-6464494858-wqpnb               1/1     Running   0          18d
coredns-7f65654f74-89x69                    1/1     Running   0          18d
coredns-7f65654f74-bznrl                    1/1     Running   2          54d
...

ServiceAccount

至于ServiceAccount怎么授权,其实相对user account来说更简单,只需先创建ServiceAccount,然后创建role或者ClusterRole,最后在RoleBinding或ClusterRoleBinding绑定即可。以下简单做一个示例,就不在显示结果了,大家可以自己去验证。

创建SA

kubectl create sa billy-sa 

创建Role

[root@node-01 rbac]# cat billy-sa-role.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: billy-sa-role
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

创建Rolebinding

将billy-sa和billy-sa-role的绑定

[root@node-01 rbac]# cat billy-sa-rolebinding.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: billy-sa-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: billy-sa-role
subjects:
- kind: ServiceAccount
  name: billy-sa

验证结果

创建完SA之后系统会自动创建一个secret,我们可以获取这个secret里面的token去登录dashboard,就可以看到相应有权限的资源。

kubectl get secret billy-sa-token-9rc55 -o jsonpath={.data.token} |base64 -d

还可以在创建pod时在pod的spec里指定serviceAccountName,那么这个pod就拥有了对应的权限,具体的就不在演示了。

本次的分享就到此,如有问题欢迎在下面留言交流,希望大家多多关注和点赞,谢谢!

推荐阅读:
  1. 怎么分析K8S与Rancher 2.0内的身份认证与授权
  2. K8s如何部署coredns

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

rbac kubernetes docker

上一篇:AVD,SDK manager 闪退

下一篇:SpringBoot全局异常处理类的使用方法

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》