日志

k8s之RBAC授权模式

 来源    2021-01-13    1  

导读

上一篇说了k8s的授权管理,这一篇就来详细看一下RBAC授权模式的使用

RBAC授权模式

基于角色的访问控制,启用此模式,需要在API Server的启动参数上添加如下配置,(k8s默然采用此授权模式)。

--authorization-mode=RBAC

  

/etc/kubernetes/manifests/kube-apiserver.yaml

  

(1)对集群中的资源及非资源权限均有完整的覆盖

(2)整个RBAC完全由几个API对象完成,同其他API对象一样,可以用kubelet或API进行操作。

(3)可在运行时进行调整,无须重启API Server

1 RBAC资源对象说明

RBAC有四个资源对象,分别是Role、ClusterRole、RoleBinding、ClusterRoleBinding

1.1 Role:角色

一组权限的集合,在一个命名空间中,可以用其来定义一个角色,只能对命名空间内的资源进行授权。如果是集群级别的资源,则需要使用ClusterRole。例如:定义一个角色用来读取Pod的权限

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac
  name: pod-read
rules:
- apiGroups: [""]
  resources: ["pods"]
  resourceNames: []
  verbs: ["get","watch","list"]

  

rules中的参数说明:

1、apiGroups:支持的API组列表,例如:"apiVersion: batch/v1"等

2、resources:支持的资源对象列表,例如pods、deplayments、jobs等

3、resourceNames: 指定resource的名称

3、verbs:对资源对象的操作方法列表。

创建后查看:

1.2 ClusterRole:集群角色

具有和角色一致的命名空间资源的管理能力,还可用于以下特殊元素的授权

1、集群范围的资源,例如Node

2、非资源型的路径,例如:/healthz

3、包含全部命名空间的资源,例如Pods

例如:定义一个集群角色可让用户访问任意secrets

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secrets-clusterrole
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","watch","list"]

  

1.3 RoleBinding:角色绑定,ClusterRoleBinding:集群角色绑定

角色绑定和集群角色绑定用于把一个角色绑定在一个目标上,可以是User,Group,Service Account,使用RoleBinding为某个命名空间授权,使用ClusterRoleBinding为集群范围内授权。

例如:将在rbac命名空间中把pod-read角色授予用户es

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-read-bind
  namespace: rbac
subjects:
- kind: User
  name: es
  apiGroup: rbac.authorization.k8s.io
roleRef:
- kind: Role
  name: pod-read
  apiGroup: rbac.authorizatioin.k8s.io

  

创建之后切换到es用户,看能否查看相应Pod的资源

RoleBinding也可以引用ClusterRole,对属于同一命名空间内的ClusterRole定义的资源主体进行授权, 例如:es能获取到集群中所有的资源信息

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: es-allresource
  namespace: rbac
subjects:
- kind: User
  name: es
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

  

创建之后查看:

集群角色绑定的角色只能是集群角色,用于进行集群级别或对所有命名空间都生效的授权

例如:允许manager组的用户读取所有namaspace的secrets

apiVersion: rabc.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secret-global
subjects:
- kind: Group
  name: manager
  apiGroup: rabc.authorization.k8s.io
ruleRef:
- kind: ClusterRole
  name: secret-read
  apiGroup: rabc.authorization.k8s.io

  

2 资源的引用方式

多数资源可以用其名称的字符串表示,也就是Endpoint中的URL相对路径,例如pod中的日志是GET /api/v1/namaspaces/{namespace}/pods/{podname}/log

如果需要在一个RBAC对象中体现上下级资源,就需要使用“/”分割资源和下级资源。

例如:若想授权让某个主体同时能够读取Pod和Pod log,则可以配置 resources为一个数组

apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata: 
  name: logs-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list"]

  

资源还可以通过名称(ResourceName)进行引用,在指定ResourceName后,使用get、delete、update、patch请求,就会被限制在这个资源实例范围内

例如,下面的声明让一个主体只能对名为my-configmap的ConFigmap进行get和update操作:

apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata:
  namaspace: default
  name: configmap-update
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["get","update"]

  

3 常见角色示例

(1)允许读取核心API组的Pod资源

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]

  

(2)允许读写extensions和apps两个API组中的deployment资源

rules:
- apiGroups: ["extensions","apps"]
  resources: ["deployments"]
  verbs: ["get","list","watch","create","update","patch","delete"]

  

(3)允许读取Pod以及读写job信息

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]、
- apiVersion: ["batch","extensions"]
  resources: ["jobs"]
  verbs: ["get","list","watch","create","update","patch","delete"]

  

(4)允许读取一个名为my-config的ConfigMap(必须绑定到一个RoleBinding来限制到一个Namespace下的ConfigMap):

rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["get"]

  

(5)读取核心组的Node资源(Node属于集群级的资源,所以必须存在于ClusterRole中,并使用ClusterRoleBinding进行绑定):

rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get","list","watch"]

  

(6)允许对非资源端点“/healthz”及其所有子路径进行GET和POST操作(必须使用ClusterRole和ClusterRoleBinding):

rules:
- nonResourceURLs: ["/healthz","/healthz/*"]
  verbs: ["get","post"]

  

4 常见的角色绑定示例

(1)用户名alice

subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io

  

(2)组名alice

subjects:
- kind: Group
  name: alice
  apiGroup: rbac.authorization.k8s.io

  

(3)kube-system命名空间中默认Service Account

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

  

(4)qa命名空间中的所有Service Account:

subjects:
- kind: Group
  name: systeml:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

  

(5)所有Service Account

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

  

(6)所有认证用户

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

  

(7)所有未认证用户

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

  

(8)全部用户

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

  

5 默认的角色和角色绑定

API Server会创建一套默认的ClusterRole和ClusterRoleBinding对象,其中很多是以“system:”为前缀的,以表明这些资源属于基础架构,对这些对象的改动可能造成集群故障。所有默认的ClusterRole和RoleBinding都会用标签kubernetes.io/boostrapping=rbac-default进行标记。

6 对Service Account的授权管理

Service Account也是一种账号,是给运行在Pod里的进程提供了必要的身份证明。需要在Pod定义中指明引用的Service Account,这样就可以对Pod的进行赋权操作。例如:pod内可获取rbac命名空间的所有Pod资源,pod-reader-sc的Service Account是绑定了名为pod-read的Role

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: rbac
spec:
  serviceAccountName: pod-reader-sc
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80

  

默认的RBAC策略为控制平台组件、节点和控制器授予有限范围的权限,但是除kube-system外的Service Account是没有任何权限的。

(1)为一个应用专属的Service Account赋权

此应用需要在Pod的spec中指定一个serviceAccountName,用于API、Application Manifest、kubectl create serviceaccount等创建Service Account的命令。

例如为my-namespace中的my-sa Service Account授予只读权限

kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace

  

(2)为一个命名空间中名为default的Service Account授权

如果一个应用没有指定 serviceAccountName,则会使用名为default的Service Account。注意,赋予Service Account “default”的权限会让所有没有指定serviceAccountName的Pod都具有这些权限

例如,在my-namespace命名空间中为Service Account“default”授予只读权限:

kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace

  

另外,许多系统级Add-Ons都需要在kube-system命名空间中运行,要让这些Add-Ons能够使用超级用户权限,则可以把cluster-admin权限赋予kube-system命名空间中名为default的Service Account,这一操 作意味着kube-system命名空间包含了通向API超级用户的捷径。

kubectl create clusterrolebinding add-ons-add-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

  

(3)为命名空间中所有Service Account都授予一个角色

如果希望在一个命名空间中,任何Service Account应用都具有一个角色,则可以为这一命名空间的Service Account群组进行授权

kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace

  

(4)为集群范围内所有Service Account都授予一个低权限角色

如果不想为每个命名空间管理授权,则可以把一个集群级别的角色赋给所有Service Account。

kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts

  

(5)为所有Service Account授予超级用户权限

kubectl create clusterrolebinding serviceaccounts-view --clusterrole=cluster-admin --group=system:serviceaccounts

  

7 使用kubectl命令行工具创建资源对象

(1)在命名空间rbac中为用户es授权admin ClusterRole:

kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac

  

(2)在命名空间rbac中为名为myapp的Service Account授予view ClusterRole:

kubctl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=rbac

  

(3)在全集群范围内为用户root授予cluster-admin ClusterRole:

kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root

  

(4)在全集群范围内为名为myapp的Service Account授予view ClusterRole:

kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=acme:myapp

  

相关文章
k8s基于RBAC的访问控制(用户授权)
日志kubernetes的API Server常用的授权插件有:   Node.ABAC.RBAC.Webhook我们重点说一下RBAC的访问控制逻辑RBAC(Role base access contr ...
2
sql-server-2008 – 如何在没有Management Studio的情况下更改SQL Server授权模式
问答有没有办法在不使用SQL Server Management Studio的情况下更改SQL Server 2008或2012中的授权模式?::以下是Management Studio将身份验证模式从 ...
1
设计模式 – 策略模式与授权模式的区别
问答策略模式与授权模式有什么区别?::策略模式是一个非常具体的设计解决方案,常见的软件问题. 战略模式意味着会有 >一个名为Strategy(或将策略作为名称的一部分)的界面.这个接口应该有一个叫做 ...
2
iphone – Objective-c异步通信:目标/动作或授权模式?
问答我正在处理一些异步通信情况(事件驱动的XML解析,NSURLConnection响应处理等).我会尽量简单解释一下我的问题: 在我目前的情况下,有一个服务提供商(可以与xml解析器通信或进行一些网络通 ...
1
java – 装饰器模式与授权模式的区别
问答装饰模式与授权模式有什么区别(如果有的话)?我不想知道实现细节,还有关于使用情况的区别和主观观点如何使用它们. > Decorator pattern > Delegation patte ...
3
c# – WCF服务授权模式
问答我正在实现一个安全的WCF服务.使用用户名/密码或Windows凭据进行身份验证.该服务托管在Windows服务进程中.现在,我正在尝试找出为每个服务操作实现授权的最佳方法. 例如,请考虑以下方法: ...
1
IdentityServer4(8)- 使用密码认证方式控制API访问(资源所有者密码授权模式)
日志一.前言 本文已经更新到 .NET Core 2.2 OAuth 2.0 资源所有者密码模式允许客户端向令牌服务发送用户名和密码,并获取代表该用户的访问令牌. 除了通过无法浏览器进行交互的应用程序之外 ...
4
IdentityServer4(7)- 使用客户端认证控制API访问(客户端授权模式)
日志一.前言 本文已更新到 .NET Core 2.2 本文包括后续的Demo都会放在github:https://github.com/stulzq/IdentityServer4.Samples (Q ...
1
k8s云集群混搭模式落地分享
日志在 <k8s云集群混搭模式,可能帮你节省50%以上的服务成本>一文中,介绍了使用k8s + 虚拟节点混合集群的方式,为负载具有时间段波峰.波谷交替规律的业务节约成本,提高服务伸缩效率的部署 ...
1
.NET Core项目实战-统一认证平台 第十一章 授权篇-密码授权模式
日志[.NET Core项目实战-统一认证平台]开篇及目录索引 上篇文章介绍了基于Ids4客户端授权的原理及如何实现自定义的客户端授权,并配合网关实现了统一的授权异常返回值和权限配置等相关功能,本篇将介绍 ...
1
IdentityServer4 实现自定义 GrantType 授权模式
日志OAuth 2.0 默认四种授权模式(GrantType): 授权码模式(authorization_code) 简化模式(implicit) 密码模式(password) 客户端模式(client_ ...
1
[k8s]zookeeper集群在k8s的搭建(statefulset模式)-pod的调度
日志之前一直docker-compose跑zk集群,现在把它挪到k8s集群里. docker-compose跑zk集群 zk集群in k8s部署 参考: https://github.com/kubern ...
1
Kubernetes RBAC授权普通用户对命名空间访问权限
日志Kubernetes RBAC授权普通用户对命名空间访问权限 官方文档:https://www.cnblogs.com/xiangsikai/p/11413970.html kind: Role ap ...
1
IdentityServer4授权模式应用场景
日志OpenID 和 OAuth 的区别 IdentityServer4,NET Core下的安全框架 客户端模式(Client Credentials) 密码模式(resource owner pass ...
1
RBAC授权
日志RBAC RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策,允许管理员通过 Kubernetes API 动态配置策略,要启用RBAC,需要在 api ...
2
IdentityServer4(客户端授权模式)
日志1.新建三个项目    IdentityServer:端口5000      IdentityAPI:端口5001    IdentityClient: 2.在IdentityServer项目中添加I ...
1
附006.Kubernetes RBAC授权
日志一 RBAC 1.1 RBAC授权 基于角色的访问控制(RBAC)是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法. RBAC使用rbac.authorization.k8s.io API ...
1
微信支持的Authorization code授权模式(公众号开发)(开放平台资料中心中的代公众号发起网页授权)
日志链接:https://blog.csdn.net/ASZJBGD/article/details/82838356 主要流程分为两步: 1.获取code 2.通过code换取accesstoken 流 ...
2
Service Account和RBAC授权
日志一.介绍 Service Account概念的引入是基于这样的使用场景:运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务.Service Accou ...
1
一步一步学习IdentityServer3 (15) 授权模式那些事
日志总结一句话,其实很简单 在什么Clients 拿的认证权限Scope 就去 去开什么Scope限制的服务接口门 在写Clients的时候,会有Scope,看下面的代码 new Client { Cli ...
2