説明
ClusterRoleBinding で cluster-admin を関連付けると、対象の主体はクラスター全体でほぼすべての権限を持ちます。設定の参照・変更・削除だけでなく、他の主体の権限変更にも使えます。本番環境では、各主体に必要な操作と範囲に権限を限定する必要があります。
想定される影響
- 一つの主体が侵害されると、クラスター全体のリソースが影響を受けるおそれがあります。
- 操作ミスで重要なリソースを変更・削除する危険が増えます。
対処方法
- 既存の cluster-admin バインドの対象と必要な操作を確認してください。参照だけなら view または必要なリソース・操作に限定したカスタムロールを使い、名前空間内の作業には RoleBinding を使ってください。
- 新しいバインドを追加しても既存の管理権限は残ります。roleRef は変更できないため、必要な管理者アクセスを確保してから既存のバインドを計画的に削除・置換し、実効権限を確認してください。
例
ロールの違いを比較する過去の例です。tiller は Helm 2 のサービスアカウント名であり、新たな Tiller の導入を推奨する例ではありません。
変更前
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-binding
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
tiller サービスアカウントにクラスター全体の管理権限を付与します。
変更後
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: view-binding
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io
別の view-binding を追加します。この ClusterRoleBinding では view もクラスター全体に適用され、元の admin-binding は別途削除する必要があります。