Pod 作成権限の過剰な付与

Pod 作成を必要な主体に限定し、デプロイできるワークロード設定も制御してください。

説明

pods の create を許可する RBAC Role または ClusterRole をバインドすると、対象の主体は許可範囲に Pod をデプロイできます。Pod の設定によっては、機密性の高い ServiceAccount や Secret、ホストマウント、特権コンテナーを利用でき、権限昇格につながる場合があります。実際の許可範囲は admission ポリシーなどの制御にも左右されます。

Pod 作成は、クラスター内に新しい実行環境を作る権限です。必要な主体だけに付与してください。

想定される影響

  • 許可された Pod 設定を通じて、より強い権限や機密データへアクセスできる場合があります。
  • 過剰な作成権限によって、リソースが消費されたり運用上の制御が弱まったりする場合があります。

対処方法

  • pods の create とワイルドカード権限は、デプロイが必要な主体だけに付与してください。通常の参照は必要な get、list、watch に限定してください。
  • 名前空間ごとの役割分離と Pod Security Admission またはポリシーエンジンで、特権とホストアクセスを制限してください。使用可能な ServiceAccount は別のポリシーで制御してください。

例

Role の作成権限だけを比較します。Role を付与するバインドと admission ポリシーは別途設定します。

変更前

hcl
resource "kubernetes_role" "role" {
  metadata {
    name = "terraform-example"
  }

  rule {
    api_groups = [""]
    resources  = ["pods"]
    verbs      = ["create", "list", "watch"]
  }
}

変更後

hcl
resource "kubernetes_role" "role" {
  metadata {
    name = "terraform-example"
  }

  rule {
    api_groups = [""]
    resources  = ["pods"]
    verbs      = ["get", "list", "watch"]
  }
}

補足:

  • 変更前: Pod 作成権限を含み、適用される制御の範囲内でワークロードをデプロイできます。
  • 変更後: 作成権限を削除し、読み取り権限だけを残します。

参考資料