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