Kubernetes の既定名前空間の使用状況の確認

名前空間を明示し、RBAC・ネットワーク・リソースのポリシーを併せて構成してください。

説明

用途の異なるワークロードを default 名前空間にまとめると、運用責任や権限の範囲を分けにくくなる場合があります。サービス、環境、チームごとにリソースを整理してください。

名前空間名だけでセキュリティ上の隔離が生じるわけではありません。実際の境界は RBAC、NetworkPolicy、リソースポリシーなどで構成する必要があります。

想定される影響

  • 別のアプリケーションのリソースを誤って変更・削除する場合があります。
  • 共有の権限やポリシーが必要以上に広く適用される場合があります。

対処方法

  • 名前空間を使用するリソースでは、意図した metadata.namespace を指定してください。クラスター全体を対象とするリソースには適用しません。
  • 対象の名前空間を先に作成し、最小権限の RBAC、必要な NetworkPolicy、ResourceQuota を構成してください。
  • 既存リソースを移す場合は、新しい名前空間での作成、依存関係、データ移行を計画し、アクセスをテストしてください。

例

必須の spec を省略したメタデータの比較です。payments 名前空間を先に用意してください。既存の kubernetes_cron_job は旧 API 用のため、現在の構成では対応する kubernetes_cron_job_v1 を使ってください。

変更前

hcl
resource "kubernetes_pod" "example" {
  metadata {
    name      = "app"
    namespace = "default"
  }
}

resource "kubernetes_cron_job" "example" {
  metadata {
    name = "batch-job"
  }
}

変更後

hcl
resource "kubernetes_pod" "example" {
  metadata {
    name      = "app"
    namespace = "payments"
  }
}

resource "kubernetes_cron_job" "example" {
  metadata {
    name      = "batch-job"
    namespace = "payments"
  }
}

補足:

  • 変更前: Pod は default を明示し、CronJob は名前空間を省略しています。省略時の実際の既定値も確認してください。
  • 変更後: 両方に payments を指定します。権限やネットワークのポリシーは別途必要です。

参考資料