k8s基础概念之十三 RBAC权限管理
作者:互联网
RBAC
rbac:基于角色的访问控制,role-based-control,他是一种基于企业内个人角色来管理一些资源的访问方法。
RBAC四种对象
Role、ClusterRole、RoleBinding、ClusterRoleBinding role:角色,报验一组权限的规则,没有拒绝规则,只是附加允许的,namespace隔离,只作用于命名空间内 clusterRole: 和role的区别,role是只作用于命名空间内。作用于整个集群。 RoleBinding:作用于命名空间内,将role绑定到user、group ClusterRoleBinding:作用于整个集群 #个人见解:局部变量,全局变量 #资源: node pod configmap等 #权限 get edit delete等 #相关常用的有ServiceAccount
RBAC在k8s集群中的两大类使用
第一类:保证在k8s上运行的pod服务具有相应的集群权限 第二类:创建能访问k8s相应资源,拥有对应权限的kube-config配置到使用k8s的人员,来作为链接k8s的凭证
配置文件说明
#role ,clusterRole …… name:ingress-nginx …… rules: - apiGroups: # 每个apigroup就是一个权限的集合 - "" resources: #当前configname下生效 - namespaces verbs: #给予的权限 - get - apiGroups: - "" resourceNames: #指定configmaps设置 - ingress-controller-leader-nginx resources: - configmaps verbs: - get - update - watch #就是-w选项 --- ### rolebinding apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding …… roleRef: apiGroup: rbac.authorization.k8s.io kind: Role #类型 name: ingress-nginx subjects: - kind: ServiceAccount name: ingress-nginx #Role绑定到ingress-nginx角色 namespace: ingress-nginx #绑定到命名空间
service account
service account 账号认证:个应用(pod)使用的账号, pod和apiservice通信时候做认证用的,如果不设置的话使用默认的 #serviceaccount 部署给kubernetes集群的用户使用的,而是给pod里面的进程使用的。它为pod提供必要的认证,只做认证,不做权限控制
Role 示例
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" 标明 core API 组 resources: ["pods"] #设置权限的资源 verbs: ["get", "watch", "list"] #设置的权限 watch 就是-w
ClusterRole 示例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: # "namespace" 被忽略,因为 ClusterRoles 不受名字空间限制 name: secret-reader rules: - apiGroups: [""] # 在 HTTP 层面,用来访问 Secret 对象的资源的名称为 "secrets" resources: ["secrets"] verbs: ["get", "watch", "list"]
RoleBinding 示例
#下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。 这样,用户 "jane" 就具有了读取 "default" 名字空间中 pods 的权限。 apiVersion: rbac.authorization.k8s.io/v1 # 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods kind: RoleBinding metadata: name: read-pods namespace: default subjects: # 你可以指定不止一个“subject(主体)” - kind: User name: jane # "name" 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系 kind: Role # 此字段必须是 Role 或 ClusterRole name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 apiGroup: rbac.authorization.k8s.io --- #例子2 apiVersion: rbac.authorization.k8s.io/v1 # 此角色绑定使得用户 "dave" 能够读取 "default" 名字空间中的 Secrets # 你需要一个名为 "secret-reader" 的 ClusterRole kind: RoleBinding metadata: name: read-secrets # RoleBinding 的名字空间决定了访问权限的授予范围。 # 这里仅授权在 "development" 名字空间内的访问权限。 namespace: development subjects: - kind: User name: dave # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding 示例
#下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 Secrets。 apiVersion: rbac.authorization.k8s.io/v1 # 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 secrets kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group name: manager # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
资源引用
在 Kubernetes API 中,大多数资源都是使用对象名称的字符串表示来呈现与访问的。 例如,对于 Pod 应使用 "pods"。 RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。 有一些 Kubernetes API 涉及 子资源(subresource),例如 Pod 的日志。 对 Pod 日志的请求看起来像这样: GET /api/v1/namespaces/{namespace}/pods/{name}/log
允许某主体读取 pods
同时访问这些 Pod 的 log
子资源,你可以这么写:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-and-pod-logs-reader rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list"]
扩展:
标签:rbac,kind,k8s,name,RBAC,io,权限,authorization 来源: https://www.cnblogs.com/RRecal/p/15699469.html