説明
Pod を作成できる利用者は、許可された名前空間でイメージ、サービスアカウント、ボリューム、セキュリティ設定を組み合わせて実行できます。実際に許可される範囲は、アドミッションポリシーなどの追加制御にも左右されます。そのため、pods の create は単なるオブジェクト作成ではなく、権限昇格につながり得る重要な権限です。
リソースや操作のワイルドカードと作成権限を組み合わせると、許可範囲が特に広くなります。Pod の作成は、必要な主体に最小限の範囲で許可してください。
想定される影響
- 強い権限のサービスアカウントや機密性の高いボリュームを使う Pod を作成されるおそれがあります。
- クラスター内での権限昇格や侵害の拡大が容易になる可能性があります。
- 広すぎる RBAC の許可により、運用上の管理が難しくなります。
対処方法
podsのcreate権限は、必要な主体だけに許可してください。resources: ["*"]やverbs: ["*"]のようなワイルドカードの組み合わせを避けてください。- RBAC の確認では、Pod 作成を特に注意が必要な権限として扱ってください。
例
ロール定義の比較です。実際の権限については、これらを付与するバインディングと、ほかのロールの許可も確認してください。
変更前
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-creator
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- "get"
- "watch"
- "create"
変更後
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- "get"
- "watch"
- "list"
説明:
- 変更前: Pod の作成を通じて、より強い実行権限を間接的に得られる可能性があります。
- 変更後: このロールでは Pod の読み取りだけを許可します。ほかのロールで作成権限を付与していないことも確認してください。