其他分享
首页 > 其他分享> > k8s基础概念之十三 RBAC权限管理

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"]

 

扩展:

https://v1-19.docs.kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#permissive-rbac-permissions

 

 

 

 

 

标签:rbac,kind,k8s,name,RBAC,io,权限,authorization
来源: https://www.cnblogs.com/RRecal/p/15699469.html