二十、K8S-1-权限管理RBAC详解

目录

k8s RBAC 权限管理详解

一、简介

二、用户分类

   1、普通用户

   2、ServiceAccount

三、k8s角色&角色绑定 

1、授权介绍:

        1.1 定义角色:

        1.2 绑定角色:

        1.3主体(subject)

2、角色(Role和ClusterRole)

 1、Role示例:

2、ClusterRole示例:

3、面向用户的默认的ClusterRole

3、角色绑定 (RoleBinding和ClusterRoleBinding)

1、RoleBinding示例:

2、ClusterRoleBinding 示例

4、对主体的引用

1、RoleBinding示例:角色绑定主体

5、对ServiceAccount的授权管理

1、为应用程序特定的服务帐户授予角色 (最佳实践)

2、在命名空间中为“默认”服务帐户(service account)授予角色

3、为命名空间中的所有服务帐户授予角色

4、对集群范围内的所有服务帐户(不鼓励)授予权限(role)

 5、将超级用户权限授予集群内的所有服务帐户(强烈反对)

6、命令行工具

1、kubectl create role

2、kubectl create clusterrole

3、kubectl create rolebinding

4、kubectl create clusterrolebinding


k8s RBAC 权限管理详解

一、简介

        基于角色(Role)的访问控制(RBAC Role Base Access Control)是一种基于组织中用户的角色来调节控制对计算机或者网络资源的访问的方法。RBAC鉴权机制使用 rbac.authorization.k8s.io API组来驱动鉴权决定, 允许你通过 Kubernetes API 动态配置策略。

        k8s 集群相关所有的交互都通过apiserver来完成,对应这样集中式管理的系统来说,权限管理尤为重要,在1.5版本时候引入了RBAC的权限控制机制

        让一个用户(Users)扮演一个角色(Role),角色拥有权限,从而让用户拥有这样的权限,随后在 授权机制当中,只需要将权限授予某个角色,此时用户将获取对应角色的权限,从而实现角色的访问 控制

        在 k8s 的授权机制当中,采用 RBAC 的方式进行授权,其工作逻辑是,把对对象的操作权限定义到 一个角色当中,再将用户绑定到该角色,从而使用户得到对应角色的权限。如果通过 rolebinding 绑定 role,只能对 rolebingding 所在的名称空间的资源有权限。另外,k8s 为此还有一种集群级别的授权机制,就是定义一个集群角色(ClusterRole),对集群内 的所有资源都有可操作的权限,从而将 User2 通过 ClusterRoleBinding 到 ClusterRole,从而使 User2 拥有集群的操作权限。

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

[root@k8s-master-1 cfg]# cat kube-apiserver.conf | grep authorization--authorization-mode=RBAC,Node \

API Server 目前支持一下集中授权策略

  • Webhook:通过调用外部REST服务对用户进行授权。
  • RBAC:Role-Based Access Control,基于角色的访问控制(本章讲解)。
  • Node:是一种专用模式,用于对kubelet发出的请求进行访问控制。

二、用户分类

        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),是给程序使用的。

工作流程图:

三、k8s角色&角色绑定 

        k8s引入了4个资源对象:Role、ClusterRole、RoleBinding、ClusterRoleBinding

1、授权介绍:

        在RBAC API中,通过如下步骤进行授权

        1.1 定义角色:

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

        Role:角色,包含一组权限的规则,没有拒绝规则,只是附加运行,namespaces隔离,只作用于命名空间。授权特定命名空间的访问权限

        ClusterRole:和Role的区别,Role只作用于命名空间内,ClusterRole作用于整个集群,也就是所有Namespace

        1.2 绑定角色:

        将主体与角色进行绑定,对用户进行访问授权

        RoleBinding:作用于命名空间内,将ClusterRole或Role绑定于主体(User、Group或ServiceAccount)

        ClusterRoleBinding:作用于整个集群,将ClusterRole或Role绑定于主体(User、Group或ServiceAccount)

        1.3主体(subject)

        User:用户

        Group:用户组

        ServiceAccount:服务账户

2、角色(Role和ClusterRole)

         角色Role是权限的定义,在k8s中角色分为两种,

        1、Role针对特定的命名空间的访问权限,

        2、ClusterRole在整个集群范围内都生效。为啥要用两种资源?因为k8s对象作用域已经被划分为集群和命名空间两部分了。

        需要注意:角色只有授权,没有禁止。

授权词

说明

get

列出单个资源

list

列出资源类型的集合

create

创建

update

修改全部资源

patch

修改部分资源

watch

动态监控

proxy

代理

redirect

重定向

use

调用

delete

删除

deletecollection

级联删除

 相关参数:构成一个role 需要三部分

  1. Verbs:设置允许对资源对象操作的方法列表,如:{“get”, “list”, “watch”, “create”, “update”, “patch”, “delete”, “exec”}
  2. resources:需要操作的资源类型列表,如:{“services”, “endpoints”, “pods”,“secrets”,“configmaps”,“crontabs”,“deployments”,“jobs”,“nodes”,“rolebindings”,“clusterroles”,“daemonsets”,“replicasets”,“statefulsets”,“horizontalpodautoscalers”,“replicationcontrollers”,“cronjobs”}
  3. apiGroups:资源对象的API组列表:"" 缺省为 core 组资源,如: “”,“apps”, “autoscaling”, “batch”
 1、Role示例:
1、命令行方式创建
kubectl create role <RoleName> [options]常用的options 如上示例:创建一个名为pod-role的role,可以操作的资源为pod,可以进行的操作为get, watch, list
[root@k8s-master-1 rbac]# kubectl create role pod-role --resource=pod --verb=get,watch,list
role.rbac.authorization.k8s.io/pod-role created2、yaml文件方式创建
[root@k8s-master-1 rbac]# vim role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: pod-rolenamespace: default
rules:
- apiGroups: [""] # "" indicates the core API groupresources: ["pods"]verbs: ["get", "watch", "list"][root@k8s-master-1 rbac]# kubectl apply -f role.yaml 
role.rbac.authorization.k8s.io/pod-role created[root@k8s-master-1 rbac]# kubectl get role 
NAME       CREATED AT
pod-role   2023-06-19T07:51:55Z[root@k8s-master-1 rbac]# kubectl describe role pod-role
Name:         pod-role
Labels:       <none>
Annotations:  <none>
PolicyRule:Resources  Non-Resource URLs  Resource Names  Verbs---------  -----------------  --------------  -----pods       []                 []              [get watch list]- - - - - - -对资源的引用 - - - - - - - - - 
kubernetes API中,大多数资源都是使用对象名称的字符串表示来呈现与访问的。例如pod 应使用"pods",有一些kubernetes API涉及子资源,
在RBAC角色表达资资源时,使用斜线(/)来分隔资源和子资源。1、要允许某主体读取pod 同时访问这些pod的log子资源
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: pod-and-pod-logs-reader
rules:
- apiGroups: [""]resources: ["pods", "pods/log"]verbs: ["get", "list"]2、对于某些请求,也可以通过resourceNames列表按名称引用资源,在指定时,可以将请求限定为资源的单个实例,
下面的例子中可以get和update 一个名为my-configmap 的 ConfigMap
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: configmap-updater
rules:
- apiGroups: [""]# 在 HTTP 层面,用来访问 ConfigMap 资源的名称为 "configmaps"resources: ["configmaps"]resourceNames: ["my-configmap"]verbs: ["update", "get"]

注意:

        如果resources:填写的资源是["pods", "services"]等,apiGroups:可以直接用空来表示所有 [""],但是如果resources中添加了["deployments"],绑定的用户在创建deployment时候就会报错,没有权限。这是为啥?

        因为apiGroups 为空的话,他只是针对单级的资源生效,

        比方说 xx 例如 apiServer: v1,就是单级的,有pod、svc、ep...

        还有两级的 比如:xx/yy 例如apiServer: apps/v1 他的父级就是apps 包括 :deployment、ds...

可以使用如下命令查看资源
kubectl apiresources 查看
示例:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: pod-rolenamespace: default
rules:
- apiGroups: ["","apps"] #因为deployments 的父级是apps ,添加了apps才会生效。resources: ["pods","deployments"]verbs: ["get", "watch", "list"]
或者deployment可以单独写个规则
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: pod-rolenamespace: default
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]
- apiGroups: ["apps"]resources: ["deployments"]verbs: ["get", "watch", "list"]
2、ClusterRole示例:
1、命令行方式创建
kubectl create clusterrole <ClusterRoleName> [options]
常用的options 如上
示例:创建一个名为pod-clusterrole的ClusterRole,可以操作的资源为pod,可以进行的操作为get, watch, list[root@k8s-master-1 rbac]# kubectl create clusterrole pod-clusterrole --resource=pod --verb=get,watch,list
clusterrole.rbac.authorization.k8s.io/pod-clusterrole created2、通过yaml文件方式创建
[root@k8s-master-1 rbac]# vim clusterrole.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: pod-clusterrolenamespace: default #被忽略,因为clusterRole不收命名空间限制
rules:
- apiGroups: [""] # "" indicates the core API groupresources: ["pods"]verbs: ["get", "watch", "list"][root@k8s-master-1 rbac]# kubectl apply -f clusterrole.yaml 
clusterrole.rbac.authorization.k8s.io/pod-clusterrole created[root@k8s-master-1 rbac]# kubectl get clusterrole |grep pod
pod-clusterrole                                                        2023-06-19T07:57:37Z[root@k8s-master-1 rbac]# kubectl describe clusterrole pod-clusterrole
Name:         pod-clusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:Resources  Non-Resource URLs  Resource Names  Verbs---------  -----------------  --------------  -----pods       []                 []              [get watch list]
3、面向用户的默认的ClusterRole

        有些系统 的默认角色不是以“system”为前缀的,这部分角色时面向用户设置的,他们包含超级用户角色 (cluster-admin), 使用 ClusterRoleBinding 的集群范围的角色 (cluster-status), 以及是用RoleBding 的具体某个 namespace中的角色 (admin, edit, view)。

默认的ClusterRole

默认的ClusterRoleBinding

描述

cluster-admin

system:masters group

允许在任何资源上执行任何操作,当通过ClusterRoleBinding 使用此角色时,授权所有民命空间下的所有资源,当使用 Rolebinding 时,授权rolebingding 所在的 命名空间下的所有资源,并包含命名空间自身所代表的资源

admin

None

允许管理员访问,一般与Rolebinding搭配使用,绑定到一个命名空间中,可以读写大多数命名空间中的资源,并且可以在命名空间中创建 role 和 rolebinding,不允许访问命名空间中的资源配额,和命名空间自身

edit

None

允许读写命名空间中的大多数资源,不过不允许查看和修改角色 (role)和角色绑定 (role binding)

view

None

允许读命名空间中的大多数资源,不过不允许查看和修改角色 (role)和角色绑定 (role binding),不允许查看secrets 资源

3、角色绑定 (RoleBinding和ClusterRoleBinding)

        上边代码块 我们定义了角色,下一步就是将角色关联到用户,角色绑定是将我们创建的角色中定义好的权限赋予给一个或者一组用户,即主体(subject),RoleBinding 在指定的命名空间中执行授权,而 ClusterRoleBinding 在集群范围执行授权。

        一个 RoleBinding 可以引用同一名字空间中的任何 Role。 或者,一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。 如果你希望将某 ClusterRole 绑定到集群中所有名字空间,你要使用 ClusterRoleBinding。

注意:

        在集群角色绑定(ClusterRoleBinding)中引用的角色只能是集群级别的角色(ClusterRole),而不能是命名空间级别的Role。

        一旦通过创建RoleBinding或者ClusterRoleBinding与某个Role或者ClusterRole完成了绑定,用户就无法修改与之绑定的Role和ClusterRole了。只有删除了RoleBinding或者ClusterRoleBinding,才能修改Role和ClusterRole。

1、RoleBinding示例:
1、命令行方式创建
1.1 先创建serviceaccount服务账户
# kubectl create sa <Name> 或 kubectl create serviceAccount <Name>
# 例如
# kubectl create serviceaccount zhangsan创建完serviceaccount服务账户之后,可以根据账户信息,查询到相应的token
[root@k8s-master-1 rbac]# kubectl describe serviceaccount zhangsan
Name:                zhangsan
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>  #自动添加到所有与该SA绑定的pod
Mountable secrets:   zhangsan-token-8n48m   
Tokens:              zhangsan-token-8n48m  #认证需要的token
Events:              <none>[root@k8s-master-1 rbac]# kubectl describe secrets zhangsan-token-8n48m
Name:         zhangsan-token-8n48m
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: zhangsankubernetes.io/service-account.uid: fdae783b-aa7d-42f5-a5e0-3856c0f50c0eType:  kubernetes.io/service-account-tokenData
====
ca.crt:     1143 bytes
namespace:  7 bytes
token:     太长删掉了1.2创建rolebinding
# kubectl create rolebinding <RBNAME> [options]
#常用options:
--role='':要进行绑定的role的name
--serviceaccount=[]:要进行绑定的clusterrole的name
--clusterrole='':要进行绑定的serviceaccount的name# 例如 将read-pods和zhangsan进行绑定,绑定后zhangsana就拥有了role中定义的规则,需要指定命名空间--serviceaccount=namespaces:zhangsan[root@k8s-master-1 rbac]# kubectl create rolebinding read-pods --role=pod-role --serviceaccount=default:zhangsan
rolebinding.rbac.authorization.k8s.io/read-pods created2、通过yaml文件方式创建
[root@k8s-master-1 rbac]# vim rolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "zhangsan" 读取 "default" 命名空间中的 Pod
。你需要在该命名空间中有一个名为 “pod-role” 的 Role
kind: RoleBinding
metadata:name: read-podsnamespace: default
subjects:
# 你可以指定不止一个“subject(主体)”
- kind: ServiceAccount/User/Groupname: zhangsan # "name" 是区分大小写的apiGroup: rbac.authorization.k8s.io    #ServiceAccount 不需要添加这行,User 需要添加 Group没试
roleRef:# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系kind: Role        # 此字段必须是 Role 或 ClusterRolename: pod-role    # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配apiGroup: rbac.authorization.k8s.io[root@k8s-master-1 rbac]# kubectl apply -f rolebinding.yaml 
rolebinding.rbac.authorization.k8s.io/read-pods created[root@k8s-master-1 rbac]# kubectl get RoleBinding
NAME        ROLE            AGE
read-pods   Role/pod-role   5s[root@k8s-master-1 rbac]# kubectl describe RoleBinding read-pods
Name:         read-pods
Labels:       <none>
Annotations:  <none>
Role:Kind:  RoleName:  pod-role
Subjects:Kind  Name      Namespace----  ----      ---------User  zhangsan 
- - - - - - -  roleBinding也可以引用clusterRole      - - - - - - - - -  - - - - - - [root@k8s-master-1 rbac]# vim rolebinding2.yaml
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "zhangsan" 读取 "default" 名字空间中的 Pod
。你需要在该名字空间中有一个名为 “pod-clusterrole” 的 ClusterRole 
kind: RoleBinding
metadata:name: read-secretsnamespace: default
subjects:
# 你可以指定不止一个“subject(主体)”
- kind: Username: zhangsan # "name" 是区分大小写的apiGroup: rbac.authorization.k8s.io
roleRef:# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系kind: ClusterRole        # 此字段必须是 Role 或 ClusterRolename: pod-clusterrole    # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配apiGroup: rbac.authorization.k8s.io[root@k8s-master-1 rbac]# kubectl apply -f rolebinding2.yaml 
rolebinding.rbac.authorization.k8s.io/read-secrets created[root@k8s-master-1 rbac]# kubectl get RoleBinding
NAME           ROLE                          AGE
read-pods      Role/pod-role                 13m
read-secrets   ClusterRole/pod-clusterrole   9s
[root@k8s-master-1 rbac]# kubectl describe RoleBinding read-secrets
Name:         read-secrets
Labels:       <none>
Annotations:  <none>
Role:Kind:  ClusterRoleName:  pod-clusterrole
Subjects:Kind  Name      Namespace----  ----      ---------User  zhangsan
2、ClusterRoleBinding 示例
1、命令行创建
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源
[root@k8s-master-1 rbac]# kubectl create clusterrolebinding read-secrets-global --clusterrole=pod-clusterrole --group=manager -n 命名空间
clusterrolebinding.rbac.authorization.k8s.io/read-secrets-global created2、yaml文件方式
[root@k8s-master-1 rbac]# vim clusterRoleBinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: read-secrets-global
subjects:
- kind: Groupname: manager      # 'name' 是区分大小写的apiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: pod-clusterroleapiGroup: rbac.authorization.k8s.io
[root@k8s-master-1 rbac]# kubectl apply -f clusterRoleBinding.yaml 
clusterrolebinding.rbac.authorization.k8s.io/read-secrets-global created
[root@k8s-master-1 rbac]# kubectl get clusterRoleBinding
NAME                                                  ROLE                                                               AGEread-secrets-global                                     ClusterRole/pod-clusterrole                                        10s

4、对主体的引用

        RoleBinding或者ClusterRoleBinding 可绑定角色到某“主体(Subject)”上。主体可以是用户、组或者服务账户。

1、RoleBinding示例:角色绑定主体

        下面示例是RoleBinding中的片段,仅展示subject的部分

1、对于名称为 alice@example.com 的用户:
subjects:
- kind: Username: "alice@example.com"apiGroup: rbac.authorization.k8s.io2、对于名称为frontend-admins 的用户组:
subjects:
- kind: Groupname: "frontend-admins"apiGroup: rbac.authorization.k8s.io3、对于kube-system 命名空间中的默认服务账户:
subjects:
- kind: ServiceAccountname: defaultnamespace: kube-system4、对于 "qa" 命名空间中的所有服务账户:
subjects:
- kind: Groupname: system:serviceaccounts:qaapiGroup: rbac.authorization.k8s.io5、对于在任何名字空间中的服务账户:
subjects:
- kind: Groupname: system:serviceaccountsapiGroup: rbac.authorization.k8s.io6、对于所有已经过身份认证的用户:
subjects:
- kind: Groupname: system:authenticatedapiGroup: rbac.authorization.k8s.io7、对于所有未通过身份认证的用户:
subjects:
- kind: Groupname: system:unauthenticatedapiGroup: rbac.authorization.k8s.io8、对于所有用户:
subjects:
- kind: Groupname: system:authenticatedapiGroup: rbac.authorization.k8s.io
- kind: Groupname: system:unauthenticatedapiGroup: rbac.authorization.k8s.io

5、对ServiceAccount的授权管理

        默认RBAC策略向控制平面(controll plane),节点和控制器授予拥有范围限制的权限,但不向“kube-system”命名空间之外的服务帐户(service account)授予权限(超出所有已验证用户的发现权限)

        从最安全到最不安全的方法是:

1、为应用程序特定的服务帐户授予角色 (最佳实践)

        这要求应用程序在其pod规范中指定serviceAccountName,并且要在之前创建好服务帐户(通过API,应用程序清单【application manifest】,kubectl 等方式创建)。

        例如,将“my-namespace”中的只读权限授予“my-sa”服务帐户:

kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace
2、在命名空间中为“默认”服务帐户(service account)授予角色

        例如,将“my-namespace”中的只读权限授予“默认”服务帐户:

 kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace
3、为命名空间中的所有服务帐户授予角色

         例如,将“my-namespace”中的只读权限授予该命名空间中的所有服务帐户:所有用户 肯定是个组啊

kubectl create rolebinding test --clusterrloe=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace
4、对集群范围内的所有服务帐户(不鼓励)授予权限(role)

        例如,将所有命名空间中的只读权限授予群集中的所有服务帐户:

kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts
 5、将超级用户权限授予集群内的所有服务帐户(强烈反对)

        在此不做演示

目录

k8s RBAC 权限管理详解

一、简介

二、用户分类

   1、普通用户

   2、ServiceAccount

三、k8s角色&角色绑定 

1、授权介绍:

        1.1 定义角色:

        1.2 绑定角色:

        1.3主体(subject)

2、角色(Role和ClusterRole)

 1、Role示例:

2、ClusterRole示例:

3、面向用户的默认的ClusterRole

3、角色绑定 (RoleBinding和ClusterRoleBinding)

1、RoleBinding示例:

2、ClusterRoleBinding 示例

4、对主体的引用

1、RoleBinding示例:角色绑定主体

5、对ServiceAccount的授权管理

1、为应用程序特定的服务帐户授予角色 (最佳实践)

2、在命名空间中为“默认”服务帐户(service account)授予角色

3、为命名空间中的所有服务帐户授予角色

4、对集群范围内的所有服务帐户(不鼓励)授予权限(role)

 5、将超级用户权限授予集群内的所有服务帐户(强烈反对)

6、命令行工具

1、kubectl create role

2、kubectl create clusterrole

3、kubectl create rolebinding

4、kubectl create clusterrolebinding


6、命令行工具

1、kubectl create role

创建Role对象,定义在某一命名空间中的权限

1、创建名称为 “pod-reader” 的 Role 对象,允许用户对 Pods 执行get、watch 和 list 操作:并创建a.yaml文件[root@k8s-master-1 rbac]# kubectl create role pod-reader --verb=get,list,watch --resource=pods -oyaml > a.yaml
role.rbac.authorization.k8s.io/pod-reader created2创建名称为 “pod-reader” 的 Role 对象并指定resourceNames:
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod3、创建名为 “foo” 的 Role 对象并指定 apiGroups:
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps4、创建名为 “foo” 的 Role 对象并指定子资源权限:
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status5、创建名为 “my-component-lease-holder” 的 Role 对象,使其具有对特定名称的资源执行 get/update 的权限:
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
2、kubectl create clusterrole
1、创建名称为 “pod-reader” 的 ClusterRole 对象,允许用户对 Pods 对象执行 get、 watch 和 list 操作:并创建a.yaml文件kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods -oyaml > a.yaml2、创建名为 “pod-reader” 的 ClusterRole 对象并指定 resourceNames:
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod3、创建名为 “foo” 的 ClusterRole 对象并指定 apiGroups:
kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps4、创建名为 “foo” 的 ClusterRole 对象并指定子资源:
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status5、创建名为 “foo” 的 ClusterRole 对象并指定 nonResourceURL:
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*6、创建名为 “monitoring” 的 ClusterRole 对象并指定 aggregationRule:
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
3、kubectl create rolebinding

        在特定的命名空间中对Role或者ClusterRole授权

1、在名字空间 “acme” 中,将名为 admin 的 ClusterRole 中的权限授予名称 “bob” 的用户: 并创建a.yaml文件
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme -oyaml > a.yaml2、在名字空间 “acme” 中,将名为 view 的 ClusterRole 中的权限授予名字空间 “acme” 中名为 myapp 的服务账户:
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme3、在名字空间 “acme” 中,将名为 view 的 ClusterRole 对象中的权限授予名字空间 “myappnamespace” 中名称为 myapp 的服务账户:
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
4、kubectl create clusterrolebinding

        在整个集群(所有命名空间)中用ClusterRole授权

1、在整个集群范围,将名为 cluster-admin 的 ClusterRole 中定义的权限授予名为 “root” 用户:并创建a.yaml文件
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root  -oyaml > a.yaml2、在整个集群范围内,将名为 system:node-proxier 的 ClusterRole 的权限授予名为 “system:kube-proxy” 的用户:
kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy3、在整个集群范围内,将名为 view 的 ClusterRole 中定义的权限授予 “acme” 名字空间中名为 “myapp” 的服务账户:
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/465969.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【玩转408数据结构】线性表——线性表的顺序表示(顺序表)

知识回顾 通过前文&#xff0c;我们了解到线性表是具有相同数据类型的有限个数据元素序列&#xff1b;并且&#xff0c;线性表只是一种逻辑结构&#xff0c;其不同存储形式所展现出的也略有不同&#xff0c;那么今天我们来了解一下线性表的顺序存储——顺序表。 顺序表的定义 …

nodejs切换版本

sudo n 18.17.0 sudo n然后键盘上下选择

进程间通信[二]

命名管道 mkfifo filename 创建管道 共享内存 systemV 就是一段内存映射到两个进程之中&#xff0c;这段内存就是双方都可以看到同一块公共空间&#xff0c;变具备了进程间通信的前提条件。把映射去掉&#xff0c;然后释放空间&#xff0c;这就是释放共享内存。 共享内存…

【开源】SpringBoot框架开发数字化社区网格管理系统

目录 一、摘要1.1 项目介绍1.2 项目录屏 二、功能模块三、开发背景四、系统展示五、核心源码5.1 查询企事业单位5.2 查询流动人口5.3 查询精准扶贫5.4 查询案件5.5 查询人口 六、免责说明 一、摘要 1.1 项目介绍 基于JAVAVueSpringBootMySQL的数字化社区网格管理系统&#xf…

量子位 | 2024年AI还能帮你干什么?这十个趋势必须关注

本文来源公众号“量子位”&#xff0c;仅用于学术分享&#xff0c;侵权删&#xff0c;干货满满。 原文链接&#xff1a;2024年AI还能帮你干什么&#xff1f;这十个趋势必须关注 大年初三&#xff0c;也不要忘记学习&#xff01;新的一年里&#xff0c;怎样能让AI多给自己帮帮…

如何升级至ChatGPT Plus:快速指南,ChatGPT的秘密武器GPT4.0是什么?

提到 ChatGPT。想必大家都有所耳闻。自从 2022 年上线以来&#xff0c;就受到国内外狂热的追捧和青睐&#xff0c;上线2个月&#xff0c;月活突破1个亿&#xff01;&#xff01;&#xff01; 而且还在持续上涨中。因为有很多人都在使用 ChatGPT 。无论是各大头条、抖音等 App、…

基于JAVA的中学生家校互联系统 开源项目

目录 一、摘要1.1 项目介绍1.2 项目录屏 二、功能模块2.1 学生管理模块2.2 课堂表现模块2.3 考试成绩模块2.4 家校留言模块2.5 校园通知模块 三、系统设计3.1 用例设计3.2 实体类设计3.2.1 课堂表现实体类设计3.2.2 考试成绩实体类设计3.2.3 家校留言实体类设计3.2.4 校园通知实…

带宽计费模式:按固定带宽和按使用流量有什么区别?

阿里云服务器带宽计费模式分为“按固定带宽”和“按使用流量”&#xff0c;有什么区别&#xff1f;按固定带宽是指直接购买多少M带宽&#xff0c;比如1M、5M、10M、100M等&#xff0c;阿里云直接分配用户所购买的带宽值&#xff0c;根据带宽大小先付费再使用&#xff1b;按使用…

JVM-类加载器 双亲委派机制

申明&#xff1a;文章内容是本人学习极客时间课程所写&#xff0c;文字和图片基本来源于课程资料&#xff0c;在某些地方会插入一点自己的理解&#xff0c;未用于商业用途&#xff0c;侵删。 什么是JVM JVM是Java Virtual Machine&#xff08;Java虚拟机&#xff09;的缩写&a…

DataBinding源码浅析---初始化过程

作为Google官方发布的支持库&#xff0c;DataBinding实现了UI组件和数据源的双向绑定&#xff0c;同时在Jetpack组件中&#xff0c;也将DataBinding放在了Architecture类型之中。对于DataBinding的基础使用请先翻阅前两篇文章的详细阐述。本文所用代码也是建立在之前工程基础之…

网络报文处理流程

报文处理流程 WLAN网络中的数据包括管理报文和业务数据报文。管理报文必须采用CAPWAP隧道进行转发&#xff0c;而业务数据报文除了可以采用CAPWAP隧道转发之外&#xff0c;还可以采用直接转发方式和Soft-GRE转发方式。 管理报文用来传送AC与AP之间的管理数据&#xff0c;存在于…

反应式编程

反应式编程 前言1 反应式编程概览2 初识 Reactor2.1 绘制反应式流图2.2 添加 Reactor 依赖 3.使用常见的反应式操作3.1 创建反应式类型3.2 组合反应式类型3.3 转换和过滤反应式流3.4 在反应式类型上执行逻辑操作 总结 前言 你有过订阅报纸或者杂志的经历吗?互联网的确从传统的…