🎖️ 建立角色(Role、ClusterRole)之後，接下來就是要分配給使用者(users)了，在社區當中，大略分為住戶和管理員兩種角色，雖然有國民身分，但在社區內的身分就要另外簽約綁定，而K8s的綁定關係，以object RoleBinding及ClusterRoleBinding處理

RBAC- RoleBinding及ClusterRoleBinding

1. RoleBinding: 顧名思義主要是綁定Role時使用，可以取namespace的任何roles綁定，另外也能綁定ClusterRole，作用範圍同樣限定在該命名空間，如果想要所有的命名空間都綁定該ClusterRole，則用ClusterRoleBinding

• 建立RoleBinding

  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: me-developer-binding
  # 綁定的對象，可以多個
  subjects:
  - kind: User
    name: me
    apiGroup: rbac.authorization.k8s.io
  roleRef:
    kind: Role
    name: developer
    apiGroup: rbac.authorization.k8s.io
  

2. ClusterRoleBinding: 綁定ClusterRole時使用

• 建立ClusterRoleBinding

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-role-binding
  # 多個綁定對象
  subjects:
  - kind: User
    name: cluster-admin
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: system:serviceaccounts:qa # 為 qa 命名空間中的所有 ServiceAccounts 绑定(複數)
    apiGroup: rbac.authorization.k8s.io
  # 目標身分
  roleRef:
    kind: ClusterRole
    name: cluster-administrator
    apiGroup: rbac.authorization.k8s.io
  

在綁定之後，就不可以再更改角色權限，如果真的要修改，就要先移除所有的綁定才行，在系統當中有一些預定義的角色及榜定，大部分名稱有前綴system:，並且標註(label)有kubernetes.io/bootstrapping=rbac-defaults，像是有核心元件的角色及綁定system:kube-scheduler、system:kube-controller-manager，以及一般元件角色system:kubelet-api-admin、system:monitoring等

RoleBinding及ClusterRoleBinding 操作指令

# 取得綁定資訊
kubectl get rolebinding <name>
kubectl describe rolebinding <name>
# 建立綁定
kubectl create rolebinding <name> --role=<roleName> --user=<userName>
# 取得綁定資訊
kubectl get clusterrolebindings
kubectl describe clusterrolebindings <name>
# 建立綁定
kubectl create clusterrolebindings <name> --clusterrole=<clusterRoleNmae> --user=<userName>

service account

除了有User這種帳戶(account)來形容使用者之外，還有另一種稱為serviceAccount，用意在於區分使用對象，可以當作是機器人帳戶，Role和serviceAccount的關係，類似於自然人與法人

• 使用對象: 給機器使用，像是workload、automation、
• serviceAccount為namespaced，在每個命名空間都有預設的serviceAccount：「defalut」，若沒有指定serviceaccount, 則在pod建立時自動錨定default

當建立serviceaccount時，預設將同步建立token(以secret型態儲存)，為外部application 讓kubernetes api驗證所用

• 情境1: 外部application，取用kubernetes api服務時，帶上token
• 情境2: 外部application以pod型態部署，將secret綁定在volume當中, 取用kubernetes服務時, 不需再手動提供token

原始的service account secret沒有時效，且綁定service account，可以禁用自動錨定token，增加安全性的策略如下：

• TokenRequestAPI: 綁定對象及物件，具時效性
• 手動生產token(from TokenRequest API): kubectl create token xxx-name
• 建立secret(不建議): 在annotation指名service account name

  apiVersion:v1
  kind: Secret
  type: kubernetes.io/service-account-token
  metadata:
    name: mysecretname
    annotaions:
      kubernetes.io/service-account.name: xxx-name
  

建立pod時能指定service account，但後續不能編輯(delete and recreate)；若以deployment的形式部署則可，其更動設定的話，會觸發新的一輪rollout

apiVersion: v1
kind: Pod
metadata:
  name: ithome-challenge
spec:
  containers:
    - name: ithome-challenge
      image: ithome-challenge
  serviceAccountName: author-sa
  automountServiceAccountToken: false # 不要自動錨定，限制pod取得的權限

service account 操作指令

# 取得service account資訊
kubectl get serviceaccount
kubectl get sa
kubectl describe serviceaccount <name>
# 建立sa
kubectl create serviceaccount <name>