首页 > 其他分享 >Kubernetes（k8s）权限管理RBAC详解

Kubernetes（k8s）权限管理RBAC详解

时间：2023-03-05 20:45:49浏览次数：49  
标签：kubectl name Kubernetes get ServiceAccount namespace RBAC Role k8s

一、简介

kubernetes 集群相关所有的交互都通过apiserver来完成，对于这样集中式管理的系统来说，权限管理尤其重要，在1.5版的时候引入了RBAC(Role Base Access Control)的权限控制机制。

启用RBAC，需要在 apiserver 中添加参数--authorization-mode=RBAC，如果使用的kubeadm安装的集群，1.6+版本都默认开启了RBAC。

$ grep -C3 'authorization-mode' /etc/kubernetes/manifests/kube-apiserver.yaml

图片

API Server目前支持以下几种授权策略：

  • AlwaysDeny：表示拒绝所有请求，一般用于测试。

  • AlwaysAllow：允许接收所有请求。
    如果集群不需要授权流程，则可以采用该策略，这也是Kubernetes的默认配置。

  • ABAC（Attribute-Based Access Control）：基于属性的访问控制。
    表示使用用户配置的授权规则对用户请求进行匹配和控制。

  • Webhook：通过调用外部REST服务对用户进行授权。

  • RBAC：Role-Based Access Control，基于角色的访问控制（本章讲解）。

  • Node：是一种专用模式，用于对kubelet发出的请求进行访问控制。

更多权限管理，可参考：http://docs.kubernetes.org.cn/51.html#Kubernetes

二、用户分类

K8s的用户分两种，一种是普通用户，一种是ServiceAccount（服务账户）。

1、普通用户

  • 普通用户是假定被外部或独立服务管理的。管理员分配私钥。平时常用的kubectl命令都是普通用户执行的。

  • 如果是用户需求权限，则将Role与User(或Group)绑定(这需要创建User/Group)，是给用户使用的。

2、ServiceAccount（服务账户）**

  • ServiceAccount（服务帐户）是由Kubernetes API管理的用户。它们绑定到特定的命名空间，并由API服务器自动创建或通过API调用手动创建。服务帐户与存储为Secrets的一组证书相关联，这些凭据被挂载到pod中，以便集群进程与Kubernetes API通信。（登录dashboard时我们使用的就是ServiceAccount）

  • 如果是程序需求权限，将Role与ServiceAccount指定(这需要创建ServiceAccount并且在deployment中指定ServiceAccount)，是给程序使用的。

相当于Role是一个类，用作权限申明，User/Group/ServiceAccount将成为类的实例。

工作流程图

图片

三、K8s角色&角色绑定（以ServiceAccount展开讲解）

1）授权介绍

在RABC API中，通过如下的步骤进行授权：

  1. 定义角色：在定义角色时会指定此角色对于资源的访问控制的规则。

  2. 绑定角色：将主体与角色进行绑定，对用户进行访问授权。

角色

  • Role：授权特定命名空间的访问权限

  • ClusterRole：授权所有命名空间的访问权限

角色绑定

  • RoleBinding：将角色绑定到主体（即subject）

  • ClusterRoleBinding：将集群角色绑定到主体

主体（subject）

  • User：用户

  • Group：用户组

  • ServiceAccount：服务账号

图解如下：

图片

2）角色（Role和ClusterRole）

Role是权限的定义，在kubernetes中角色分为两种一种是Role针对特定的命名空间，一种是ClusterRole在整个集群范围内都生效。

Role示例如下：

cat >Role-001.yaml<<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-role
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
EOF
$ kubectl apply -f Role-001.yaml
$ kubectl get role -n default
$ kubectl describe role pod-role -n default

图片

ClusterRole示例如下:

cat >ClusterRole-001.yaml<<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
EOF
$ kubectl apply -f ClusterRole-001.yaml
$ kubectl get clusterrole pod-clusterrole
$ kubectl describe clusterrole pod-clusterrole

图片

相关参数
1、Role、ClsuterRole Verbs可配置参数

"get", "list", "watch", "create", "update", "patch", "delete", "exec"

2、Role、ClsuterRole Resource可配置参数

"services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs","nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets","horizontalpodautoscalers","replicationcontrollers","cronjobs"

3、Role、ClsuterRole APIGroup可配置参数

"","apps", "autoscaling", "batch"

3）角色绑定（RoleBinding和ClusterRoleBinding）

定义好了角色也就是一个权限的集合，然后创建了一个ServiceAccount也就是一个服务账号，然后将这两个东西绑定起来，就是授权的过程了。

1、Role角色绑定ServiceAccount

$ cat >RoleBinding-001.yaml<<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rb
  namespace: default
subjects:
- kind: ServiceAccount
  name: zhangsan
  namespace: default
roleRef:
  kind: Role
  name: pod-role
  apiGroup: rbac.authorization.k8s.io
EOF
$ kubectl apply -f RoleBinding-001.yaml
$ kubectl get RoleBinding
$ kubectl describe RoleBinding rb

图片

2、ClusterRole角色绑定ServiceAccount

$ cat >ClusterRoleBinding-001.yaml<<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: crb
subjects:
- kind: ServiceAccount
  name: mark
  namespace: default
roleRef:
  kind: ClusterRole
  name: pod-clusterrole
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mark
  namespace: default
EOF
$ kubectl apply -f ClusterRoleBinding-001.yaml
$ kubectl get ClusterRoleBinding crb
$ kubectl describe ClusterRoleBinding crb

图片

上面只是说到了绑定ServiceAccount，其实还有两种类型：User，Group，绑定类似，把subjects.kind。

四、实战

尽管无法通过 API 调用来添加给kubernetes增加普通用户，Kubernetes 仍然认为能够提供由集群的证书 机构签名的合法证书的用户是通过身份认证的用户。基于这样的配置，Kubernetes 使用证书中的 'subject' 的通用名称（Common Name）字段（例如，"/CN=devuser"）来 确定用户名， Kubernetes使用证书中的 'subject' 的单位名称 (Organization Name) 字段（例如，"/O=system:masters"）来确定用户组。接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对 某资源执行特定的操作。

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

  • system:unauthenticated ：未能通过任何一个授权插件检验的账号，即未通过认证测 试的用户所属的组 。

  • system :authenticated ：认证成功后的用户自动加入的一个组，用于快捷引用所有正常通过认证的用户账号。

  • system : serviceaccounts ：当前系统上的所有 Service Account 对象。

  • system :serviceaccounts :<namespace＞：特定命名空间内所有的 Service Account 对象。

1）User

1、创建K8S 用户

普通用户并不是通过k8s来创建和维护，是通过创建证书和切换上下文环境的方式来创建和切换用户。

a、创建证书

#　创建私钥
$ openssl genrsa -out devuser.key 2048
 
#　用此私钥创建一个csr(证书签名请求)文件
$ openssl req -new -key devuser.key -subj "/CN=devuser" -out devuser.csr
 
#　拿着私钥和请求文件生成证书
$ openssl x509 -req -in devuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out devuser.crt -days 365

b、生成账号

$ kubectl config set-credentials devuser --client-certificate=./devuser.crt --client-key=./devuser.key --embed-certs=true

c、设置上下文参数

# # 设置上下文， 默认会保存在 $HOME/.kube/config
$ kubectl config set-context devuser@kubernetes --cluster=kubernetes --user=devuser --namespace=dev

# 查看
$ kubectl config get-contexts

图片

d、设置 默认上下文

$ kubectl config use-context devuser@kubernetes
# 查看
$ kubectl config get-contexts
$ kubectl get nodes

图片

发现使用我们创建的用户查询是失败的，是因为账号还没授权，接下来就是对账号进行授权。这里需要先把用切回来，要不然就无法进行下一步授权了。

$ kubectl config use-context kubernetes-admin@kubernetes
$ kubectl get nodes

图片

2、对用户授权

$ cat >devuser-role-bind<<EOF
kind: Role  # 角色
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: dev
  name: devuser-role
rules:
- apiGroups: [""] # ""代表核心api组
  resources: ["pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: RoleBinding # 角色绑定
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: devuser-rolebinding
  namespace: dev
subjects:
- kind: User
  name: devuser   # 目标用户
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: devuser-role  # 角色信息
  apiGroup: rbac.authorization.k8s.io
EOF

执行并验证

$ kubectl apply -f devuser-role-bind
$ kubectl config use-context devuser@kubernetes
$ kubectl get pods # 不带命名空间，这里默认dev，也只能查看dev上面限制的命名空间的pods资源，从而也验证了role是针对命名空间的权限限制
#查看其它命名空间的资源
$ kubectl get pods -n default
$ kubectl get pods -n kube-system
$ kubectl get nodes

图片

可以看到，用devuser，已经可以管理dev命名空间下的pod资源了，也只能管理dev命名空间下的pod资源，无法管理dev以外的资源类型，验证ok。ClusterRoleBinding绑定类似，这里就不重复了。有兴趣的小伙伴可以试试。

切回管理员用户

$ kubectl config use-context kubernetes-admin@kubernetes

2）Group

因为跟user类型，这里就不过多文字介绍，直接上命令和配置

1、创建K8S 用户和用户组

#　创建私钥
$ openssl genrsa -out devgroupuser.key 2048
 
#　用此私钥创建一个csr(证书签名请求)文件
$ openssl req -new -key devgroupuser.key -subj "/O=devgroup/CN=devgroupuser" -out devgroupuser.csr
 
#　拿着私钥和请求文件生成证书
$ openssl x509 -req -in devgroupuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out devgroupuser.crt -days 365

# 生成账号
$ kubectl config set-credentials devgroupuser --client-certificate=./devgroupuser.crt --client-key=./devgroupuser.key --embed-certs=true

# 设置上下文参数
$ kubectl config set-context devgroupuser@kubernetes --cluster=kubernetes --user=devgroupuser --namespace=dev

# 查看
$ kubectl config get-contexts

图片

2、对组授权

$ cat >devgroup-role-bind.yaml<<EOF
kind: Role  # 角色
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: dev
  name: devgroup-role
rules:
- apiGroups: [""] # ""代表核心api组
  resources: ["services","pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: RoleBinding # 角色绑定
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: devgroup-rolebinding
  namespace: dev
subjects:
- kind: Group
  name: devgroup   # 目标用户组
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: devgroup-role  # 角色信息
  apiGroup: rbac.authorization.k8s.io
EOF

执行并验证（命名空间默认dev，而不是系统的default）

$ kubectl apply -f devgroup-role-bind.yaml
#切用户
$ kubectl config use-context devgroupuser@kubernetes
# 查看
$ kubectl config get-contexts
$ kubectl get pods
$ kubectl get svc
$ kubectl get nodes
$ kubectl get jobs

图片

从上图实验看，只能管理dev命名空间下的pods和services了，验证ok。

切回管理员用户

$ kubectl config use-context kubernetes-admin@kubernetes

3）ServiceAccount

上面第四节，已经很详细的介绍了ServiceAccount，这里也是直接上配置和操作命令。

$ cat >RoleBinding-ServiceAccount-001.yaml<<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: role001
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rb001
  namespace: default
subjects:
- kind: ServiceAccount
  name: lisi
  namespace: default
roleRef:
  kind: Role
  name: role001
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: lisi
  namespace: default
EOF

执行

$ kubectl delete -f RoleBinding-ServiceAccount-001.yaml

4）为ServiceAccount生成Token

cat >ClusterRoleBinding-ServiceAccount-token-001.yaml<<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: sa001
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa001
  namespace: kube-system
EOF

获取token

$ kubectl -n kube-system get secret|grep sa001
$ kubectl -n kube-system describe secret sa001-token-c2klg
# 也可以使用 jsonpath 的方式直接获取 token 的值，如：
$ kubectl -n kube-system get secret sa001-token-c2klg -o jsonpath={.data.token}|base64 -d

图片

【注意】yaml 输出里的那个 token 值是进行 base64 编码后的结果

5）默认的Token

每次创建了新的namespace下都会生成一个默认的token，名为default-token-xxxx。default就相当于该namespace下的一个用户。

$ kubectl -n dev get secret
$ kubectl -n dev describe secret default-token-67wgz
# 也可以使用 jsonpath 的方式直接获取 token 的值，如：
$ kubectl -n dev get secret default-token-67wgz -o jsonpath={.data.token}|base64 -d

图片

可以使用下面的命令给该用户分配该namespace的管理员权限

kubectl create rolebinding $ROLEBINDING_NAME --clusterrole=admin --serviceaccount=$NAMESPACE:default --namespace=$NAMESPACE

  • $ROLEBINDING_NAME必须是该namespace下的唯一的

  • admin表示用户该namespace的管理员权限，关于使用clusterrole进行更细粒度的权限控制请参考RBAC——基于角色的访问控制。

  • 我们给默认的serviceaccount default分配admin权限，这样就不要再创建新的serviceaccount，当然你也可以自己创建新的serviceaccount，然后给它admin权限

其实kubernetes-dashboard就是通过token授权的，可以不清楚的，可以看我之前的文章：Kubernetes（k8s）安装以及搭建k8s-Dashboard详解

五、总结

RoleBinding 和 ClusterRoleBinding：角色绑定和集群角色绑定，简单来说就是把声明的 Subject 和我们的 Role 进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding 只会影响到当前namespace 下面的资源操作权限，而 ClusterRoleBinding 会影响到所有的namespace。

  • Rule：规则，规则是一组属于不同 API Group 资源上的一组操作的集合

  • Role 和 ClusterRole：角色和集群角色，这两个对象都包含上面的 Rules 元素，二者的区别在于，在 Role 中，定义的规则只适用于单个命名空间，也就是和namespace 关联的，而 ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。另外 Role 和 ClusterRole 在Kubernetes中都被定义为集群内部的 API 资源，和我们前面学习过的 Pod、ConfigMap 这些类似，都是我们集群的资源对象，所以同样的可以使用我们前面的kubectl相关的命令来进行操作

  • Subject：主题，对应在集群中尝试操作的对象，集群中定义了3种类型的主题资源：

  1. User：用户，这是有外部独立服务进行管理的，管理员进行私钥的分配，用户可以使用 KeyStone或者 Goolge 帐号，甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象，所以用户不能通过集群内部的 API 来进行管理

  2. Group：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如cluster-admin

  3. ServiceAccount：服务帐号，通过Kubernetes API 来管理的一些用户帐号，和namespace 进行关联的，适用于集群内部运行的应用程序，需要通过 API 来完成权限认证，所以在集群内部进行权限操作，我们都需要使用到 ServiceAccount，这也是我们这节课的重点

标签：kubectl,name,Kubernetes,get,ServiceAccount,namespace,RBAC,Role,k8s
From： https://www.cnblogs.com/cheyunhua/p/17181566.html

相关文章

  • K8S 实用工具之三 - 图形化 UI Lens
    开篇......
  • Kubernetes的工作机制
    云计算时代的操作系统Kubernetes是一个生产级别的容器编排平台和集群管理系统，能够创建、调度容器，监控、管理服务器。Kubernetes的基本架构操作系统的一个重要功能就是......
  • K8S CKA 1.26 模拟环境 实验环境（一键导入） Kubernetest v1.26题库
    K8SCKA1.26考试环境，按照CKA最新原题搭建的，模拟环境已集成考题，可直接模拟练习，做题实操。资料包含：2023年3月最新题库+答案解析+考试笔记+模拟环境+技术支持+在线辅导答疑......
  • minikube搭建Kubernetes环境
    前言Kubernetes一般都运行在大规模的计算集群上，管理很严格，Kubernetes充分考虑到了这方面的需求，提供了一些快速搭建Kubernetes环境的工具。minikube它是一个“迷你”......
  • K8S 实用工具之二 - 终端 UI K9S
    开篇......
  • K8S对外服务之Ingress
    一、Ingress简介service的作用体现在两个方面，对集群内部，它不断跟踪pod的变化，更新endpoint（端点）中对应pod的对象，提供了ip不断变化的pod的服务发现机制；对集群外部，他类似负载......
  • k8s-安装负载均衡器
    本文章是 k8s二进制高可用集群部署 的分支。详细步骤请参考目录。k8s的LoadBalancer类型的Service依赖于外部的云提供的LoadBalancer。当我们把k8s部署在裸......
  • 微服务 - 搭建k8s(minikube)与简单wordPress实战
    Kubernetes的基本架构Kubernetes的基本架构，由Matser和Node子节点组成，使用kubectl进行通信，Master里的组件有哪些:Master里有4个组件，分别是apiserver、etcd、schedu......
  • 基于k8s构建企业jenkins CICD（二）
    1.Jenkins配置安装插件：kubernetes、git、pipeline、kubernetescontinuousdeploy配置Jenkins挂钩k8s环境点击“系统管理”=》“系统设置”。一直往下滑动，点击“新增一个云......
  • Rancher 使用介绍（可以通过界面管理 K8s 平台）
    参考链接https://blog.csdn.net/weixin_46902396/article/details/122433622https://www.hugedomains.com/domain_profile.cfm?d=kukasoft.comhttps://ranchermanager.d......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99