前言

誠如前一回所提到，蓋一座叢集不太可能只拿來自己用，大家共用的情況下，勢必是要面臨管控使用者怎麼做事情的課題⋯⋯在前面有提到，要讓士農工商各司其職

RBAC 是什麼

大家應該都會於「註冊帳號、設定密碼」這件事情不陌生。 假設你是一家公司的新進員工，通常都會拿到一個信箱，然後透過這個信箱或帳號，登入公司的內部系統。 然後隨著工作的需要，會需要去使用或管理其他的系統。 此時如果你每碰到一個新的系統，就重新申請一個新的帳號和密碼，那麼除了個別系統需要走一次申請帳號流程，還需要耗費多餘的心力來管理使用者的權限。 最可怕的是，當你多年後要離職，搞不好你自己都不記得曾經申請過哪些系統。

因此誕生了 RBAC（Role-Based Access Control，角色式存取控制）也是 Kubernetes 與 OpenShift 中最核心的權限管理機制，用來定義「誰（使用者/群組）可以對哪些資源做什麼事」。

誰 / 使用者 / 群組 / 服務帳戶

• 「使用者(User)」 可以單獨存在，也可以加入一個或多個 「使用者群組(User Group)」。
• 不屬於人類使用的誰，叫做 「服務帳戶(Service Account)」。

權限單位

• 透過 「角色(Role)」 來賦予屬於該「角色」對應到不同資源，分別具有哪些權限。
• 透過 「叢集角色(ClusterRole)」 來賦予屬於該「角色」在整座叢集中可以做什麼的權限。

授權機制

• 以 「RoleBinding(角色綁定)」/ 「ClusterRoleBinding」(叢集角色綁定) 來授權那個「誰」。

四大元素

在上述的 K8s / OCP 的 RBAC 機制中，可以配合下方表格來確認設想的權限是否完善。

與 AWS IAM 比較

作為慣用 AWS 的使用者，不免俗地比較 AWS IAM 和 OCP。 進行這種比較，日後好同時理解慣用 OCP 和慣用 AWS 的術語及類比解釋給對方聽。

管理流程

# 1. 建立使用者
oc create user alice

# 2. 加入群組
oc adm groups new dev-team
oc adm groups add-users dev-team alice

# 3. 指派角色
oc adm policy add-role-to-user edit alice -n dev

結論

• 最小權限實踐（Principle of Least Privilege, PoLP），是避免使用者做超過分外的操作，避免使用者給驚嚇。

參考資料

1. https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/authentication_and_authorization/using-rbac#default-roles_using-rbac
2. https://docs.aws.amazon.com/zh_tw/eks/latest/userguide/default-roles-users.html