kubernetes實踐之十六：RBAC 角色訪問控制

百聯達發表於2018-04-14
一：RBAC體系結構

二：RBAC角色繫結流程

三：說明
1.RBAC的優勢
a.對叢集中的資源和非資源許可權均有完整覆蓋
b.RBAC由API物件完成，可以用Kubectl或API進行操作
c.可以在允許時進行調整，無須重新啟動API Server

2.Role
一個角色就是一組許可權的集合，在一個名稱空間中，可以使用Role定義一個角色，如果是叢集級別的可以使用ClusterRole.

3.ClusterRole
除了和Role一樣具有名稱空間內資源的管理能力，還可以用於特殊元素的授權。如：
a.叢集範圍的資源，node等
b.非資源型的路徑，如“/healthz”
c.涵蓋全部名稱空間的資源

4.RoleBinding和ClusterRoleBinding
兩者用於把一個角色繫結到一個目標上，如User,Group或Service Account. RoleBinding可以引用Role和ClusterRole, ClusterRoleBinding僅可以引用ClusterRole.

5.對資源的引用方式
a.使用“/”來分隔資源和下級資源  如：resources: ["pods", "pods/log"]
b.透過名字進行引用   如：resourceNames: ["my-configmap"]

6.常用角色示例
a.執行讀取核心API組中的POD資源

點選(此處)摺疊或開啟

  1. rules:
  2. - apiGroups: [""]
  3.   resources: ["pods"]
  4.   verbs: ["get", "list", "watch"]
b.執行讀寫“extensions”和"apps"兩個API組中的deployment資源

點選(此處)摺疊或開啟

  1. rules:
  2. - apiGroups: ["extensions", "apps"]
  3.   resources: ["deployments"]
  4.   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
7.常用角色繫結示例
a.繫結Kube-system名稱空間中預設的service-account

點選(此處)摺疊或開啟

  1. subjects:
  2. - kind: ServiceAccount
  3.   name: default
  4.   namespace: kube-system
b.qa名稱空間中的所有service account

點選(此處)摺疊或開啟

  1. subjects:
  2. - kind: Group
  3.   name: system:serviceaccounts:qa
  4.   apiGroup: rbac.authorization.k8s.io
c.所有認證使用者

點選(此處)摺疊或開啟

  1. subjects:
  2. - kind: Group
  3.   name: system:authenticated
  4.   apiGroup: rbac.authorization.k8s.io
8.對Service Account的授權管理
kube-system之外的service account 是沒有任何許可權的，這就需要使用者為service account賦予所需的許可權。如：

點選(此處)摺疊或開啟

  1. kubectl create rolebinding default-view \
  2.   --clusterrole=view \
  3.   --serviceaccount=my-namespace:default \
  4.   --namespace=my-namespace






來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28624388/viewspace-2152940/，如需轉載，請註明出處，否則將追究法律責任。

相關文章