【K8sセキュリティ】 “とりあえず動く”から堅牢な本番環境へ移行！10のチェックリスト

コンテナ技術、特にKubernetes（クバネティス）の普及により、アプリケーション開発の速度は飛躍的に向上しました。しかし、その一方でセキュリティ対策が後手に回り、「とりあえず動いている」状態の本番環境が増えているのではないでしょうか。

この記事では、日々の運用に追われるインフラエンジニアやSREの皆さんが、自信を持って「堅牢だ」と言える本番環境を構築するために、最低限実施すべき10のセキュリティチェックリストを、公式ドキュメントも参考にしながら、具体的に解説します。

この記事を読み終える頃には、自社の環境に潜むリスクを特定し、具体的な改善アクションを始められるようになっているはずです。

1. Distrolessで、攻撃対象領域を削減

Distrolessとは、Googleが提供する、アプリケーションの実行に必要な最小限の依存関係のみを含んだコンテナイメージです。アプリケーションとその実行時の依存関係のみを含むように設計されるため、非常に軽量なことが特徴です。

コンテナイメージには、アプリケーションの実行に不要なOSコマンドやライブラリが含まれていることが多く、これらが脆弱性の温床となります。Distrolessイメージを利用することで、不要なツール（シェルやパッケージマネージャなど）を排除し、攻撃対象領域を大幅に削減できます。

これにより、脆弱性スキャナのノイズが減り、本当に重要な問題に集中できるようになるという副次的な効果も期待できます。

2. PSAで、Podの振る舞いを制限

Kubernetes v1.25で安定版（Stable）となったPod Security Admission (PSA) は.、Podのセキュリティに関する要求をnamespaceレベルで強制するための組み込みアドミッションコントローラです。

これは、非推奨となったPodSecurityPolicy (PSP) に代わるもので、よりシンプルで柔軟なセキュリティポリシーの適用を可能にします。（参考記事）

PSAでは、「privileged」「baseline」「restricted」という3つのPodセキュリティ標準が定義されています。

プロファイル	説明
privileged	制限がなく、最も広範な権限を許可するポリシー。
baseline	既知の特権昇格を防ぐ、最小限の制限を持つポリシー。
restricted	現在のPod強化のベストプラクティスに従う、非常に制限の厳しいポリシー。

開発段階では「baseline」を適用し、本番環境では可能な限り「restricted」ポリシーを適用することで、コンテナの不要な権限を剥奪し、セキュリティリスクを大幅に低減できます。

3. RBACで、最小権限の原則を徹底

Role-Based Access Control (RBAC) は、誰がどのリソースに対して何を実行できるかを制御する、Kubernetesセキュリティの要です。

ユーザーやサービスアカウントには、業務に必要な最小限の権限のみを付与する「最小権限の原則」を徹底することが重要です。特に、namespaceレベルでの権限付与（RoleとRoleBinding）を基本とし、クラスタ全体に影響を及ぼすClusterRoleやClusterRoleBindingの使用は慎重に行うべきです。

また、ワイルドカードによる権限付与は、将来追加されるリソースへの意図しないアクセス許可につながる可能性があるため、避けるようにしましょう。