kubernetesのservice accountとデフォルトの権限を理解する

kubernetesでRBACを利用する場合、service account(以下sa）を作成するとどのような権限が割り当てられているか把握できていますでしょうか。私はできていなくて、環境によってsaを作った時のデフォルト権限がなんか違う気がし、もやもやしていたので調べました。

• 想定読者
  • KubernetesのRBACの概要は理解している
  • KubernetesのRBAC関連リソースを理解している
    • Role
    • RoleBinding
    • ClusterRole
    • ClusterRoleBinding

結論

• 全てのsaは「system:serviceaccounts」グループに属する
  • つまりsystem:serviceaccountsグループに対して許可した権限は全てのsaに適用される
• 環境によってはsystem:serviceaccountsに対してデフォルトで権限が与えられている
  • 例えばdocker-desktopではcluster-admin権限が与えられている
  • 他のKubernetes環境(EKSなど）を使った時に仕様を理解していないと挙動の違いに悩まされる

結論は簡単ですが、上記の内容は重要な仕様なわりにドキュメントにさらっと書かれているので理解が遅れました、、、、。

環境の違い

system:serviceaccountsなどの設定は環境によってデフォルトで作成されていたり、されてなかったりするのでややこしいです。

docker-desktop

例えばdocker-desktopを確認してみると、以下のようなClusterRoleBindingsがデフォルトで作成されています。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: docker-for-desktop-binding
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/docker-for-desktop-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts

つまり、saを作成するとデフォルトでcluster-adminという強い権限が与えられます。（かなり危険ですね。）

EKS

EKSの場合はsystem:serviceaccountsに関するClusterRoleBindingsはデフォルトでは作成されていません。つまりsaを作成して管理者が権限を与えない限り、saは権限を持ちません。

まとめ

内容として少ないですが、RBACを理解するうえでコアなsaの仕様を紹介しました。

参考URL

• Using RBAC Authorization - Kubernetes