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