RBA授权模式

RBA(Role-Based Access ontrol,基于角色的访问控制),在Kubernetes1.5中引入,在v1.6版本升级为Beta版本,并成为kubeadm安装方式下的默认选项.

RBA有如下优势

1.对集群中的资源和非资源权限具有完整的覆盖 2.整个RBA完全由几个API对象完成,同其他API对象一样,可以用kubectl或API进行操作 3.可以在运行时进行调整,无须重新启动API Server

要使用RBA授权模式,则需要在API Server的启动参数中加上--authorization-mode=RBA

ABA与RBA

ABA,基于属性的访问控制,是一个强大的概念。但是,正如Kubernetes所实施的那样,ABA很难管理和理解。它需要在群集的主VM上进行ssh和root文件系统访问才能进行授权策略更改。要使权限更改生效,必须重新启动群集API服务器。

RBA权限策略使用kubectl或Kubernetes API直接配置。可以授权用户使用RBA本身进行授权策略更改,从而可以委派资源管理,而无需向集群主机发送ssh访问权限。RBA策略可轻松映射到Kubernetes API中使用的资源和操作。

根据Kubernetes社区关注其开发工作的地方,前进RBA应优先于ABA


基本概念

RBA的核心是为用户提供对Kubernetes API资源的细粒度访问。 rba

用户和资源之间的连接在RBA中使用两个对象定义。

角色(Role) 一个角色就是一组权限的集合,这里的权限都是许可形式的,不存在拒绝的规则.在一个命名空间中,可以用一个角色定义一个角色,如果是集群级别的,就需要使用lusterRole了

一个角色只能用于授予对单个命名空间内的资源的访问权限。 以下是Role“默认”命名空间中的一个示例,可用于授予对pod的读取权限:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group (空字符串,表示核心API群)
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Copyright © i4t.com 2019 all right reserved,powered by Gitbook该文件修订时间: 2019-04-26 21:31:27

results matching ""

    No results matching ""