説明
Pod とコンテナーの security_context は、実行ユーザー、権限昇格、ファイルシステム、capability を制御します。必要な制限を定めず環境の既定値だけに依存すると、想定より広い権限で実行される場合があります。
明示的なブロックがなくても、イメージ、ランタイム、親 Pod の設定、アドミッションポリシーによって値が設定される場合があります。ブロックの有無だけでなく、実際に適用された値を確認してください。
想定される影響
- コンテナーが必要以上の権限で実行される場合があります。
- 環境ごとの既定値により、セキュリティ基準が一貫しなくなる場合があります。
対処方法
- 対応する階層で security_context を設定し、非 root 実行、最小限の capability、読み取り専用ルートファイルシステムなど、必要な制限を適用してください。
- run_as_non_root は Pod またはコンテナーで、allow_privilege_escalation はコンテナーで設定してください。共通フィールドはコンテナー側で Pod の値を上書きできるため、最終的な値を確認してください。
- イメージの実行ユーザーとファイル・ポートの権限を合わせ、起動と通常動作をテストしてください。
例
var.non_root_image には、数値の非ゼロ USER で実行され、必要なファイル・ポート権限に対応する保守されているイメージを指定してください。既存の nginx:1.7.9 は既定で root を使用する古い版のため、変更後の構成には適していません。
変更前
hcl
resource "kubernetes_pod" "example" {
metadata {
name = "terraform-example"
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
変更後
hcl
resource "kubernetes_pod" "example" {
metadata {
name = "terraform-example"
}
spec {
security_context {
run_as_non_root = true
}
container {
image = var.non_root_image
name = "example"
security_context {
allow_privilege_escalation = false
}
}
}
}
補足:
- 変更前: 明示的なセキュリティコンテキストがありません。実際の権限はイメージや適用されたポリシーも確認する必要があります。
- 変更後: Pod で非 root 実行を要求し、コンテナーの権限昇格を制限します。対応するイメージを別途指定する必要があります。