概要
Kubernetes のセキュリティに対処するには、ビルドの段階で既知のセキュリティ脆弱性を修正し、ビルドあるいはデプロイの段階で構成ミスを再構成し、ランタイムで脅威に対応することが求められます。このことは、最新のレポート「Kubernetes とコンテナのセキュリティの現状」の中で集められた回答からもわかります。このレポートによると、深刻なコンテナセキュリティの問題の原因の 24% は修正可能な脆弱性、70% 近くが構成ミス、27% がランタイム中のセキュリティインシデントです。
Kubernetes のセキュリティリスクとは
コンテナは至る所にある
Kubernetes は、クラスタにまとめられた数百 (場合によっては数千) の Linux® コンテナを管理するために使用されるオープンソースのコンテナ・オーケストレーション・プラットフォームです。コンテナ化されたマイクロサービスを接続するアプリケーション・プログラミング・インタフェース (API) に大きく依存しています。この分散性により、どのコンテナに脆弱性があるのか、どのコンテナの構成に誤りがあるのか、どのコンテナが組織に最大のリスクをもたらす可能性があるのかを迅速に調査することは困難になります。
解決策は、各コンテナの重要なシステムレベルのイベントをキャプチャするコンテナ・デプロイメントを包括的に捉えられるようにすることです。
KuppingerCole Report Leadership Compass：コンテナのセキュリティ
コンテナと Kubernetes のセキュリティ市場に関する包括的な概要を確認して、適切なコンテナ・セキュリティ・ソリューションの評価と選択に役立てましょう。
イメージやレジストリが誤用される可能性がある
コンテナイメージ (ベースイメージとも言う) は、新しいコンテナの作成に使用される不変のテンプレートです。新しくコピーしたコンテナイメージは、目的に応じて変更することができます。
解決策は、イメージの作成方法とイメージレジストリへの保存方法を決定するポリシーを設定することです。ベースイメージは、定期的にテスト、承認、スキャンする必要があります。また、Kubernetes 環境でコンテナを起動するには、許可されたイメージレジストリのイメージのみを使用する必要があります。
コンテナ通信に制約がない
コンテナと Pod は、適切に機能するために、デプロイメント内で相互に通信する必要があります。また、他の内部および外部エンドポイントとも通信する必要があります。コンテナが侵害された場合、ハッカーが環境内を移動できるかどうかは、そのコンテナが他のコンテナや Pod とどれだけ広く通信できるかに直接関係しています。広大なコンテナ環境では、そのようなポリシーは手動で構成するには複雑すぎることから、ネットワーク・セグメンテーションの実装が非常に困難な場合があります。
解決策は、名前空間、デプロイメント、および Pod 間を移動するトラフィックを追跡し、そのトラフィックのうちどれだけが実際に許可されるかを決定することです。
デフォルトのコンテナ・ネットワーク・ポリシー
デフォルトでは、Kubernetes デプロイメントは、Kubernetes アプリケーションの最小単位である Pod にネットワークポリシーを適用しません。これらのネットワークポリシーは、ファイアウォールルールのように機能し、Pod の通信方法を制御します。ネットワークポリシーがなければ、どの Pod も他のあらゆる Pod と通信できます。
解決策は、Pod の通信を定義されたアセットのみに制限するネットワークポリシーを定義し、シークレットを環境変数として渡すのではなく、コンテナ内の読み取り専用ボリュームにマウントすることです。
コンテナと Kubernetes のコンプライアンス
Kubernetes によって促進されるクラウドネイティブ環境は (他のすべての IT 環境と同様に)、セキュリティのベストプラクティス、業界標準、ベンチマーク、そして組織内部のポリシーに準拠し、そのコンプライアンスを証明する必要があります。そのため、元々は従来のアプリケーション・アーキテクチャ用に作成された制御に Kubernetes 環境が適合するように、コンプライアンス戦略を変えることになる場合があります。
解決策は、コンプライアンスの順守を監視し、監査を自動化することです。
ランタイム
Kubernetes は不変のインフラストラクチャです。コンテナの実行中はパッチを適用できません。実行中のコンテナを破棄して再作成する必要があります。不正アクセスを受けたコンテナは、クリプトマイニングやポートスキャンなど、悪意のあるプロセスを実行する可能性があります。
解決策は、侵害されたコンテナや実行中のコンテナを破棄し、危険のないコンテナイメージを再構築してから、再起動することです。
ビルド段階のセキュリティ
Kubernetes セキュリティは、ビルドの段階で強力なベースイメージを作成し、脆弱性スキャンのプロセスを導入することから始まります。
最小限のベースイメージを使用する：オペレーティングシステム (OS) のパッケージマネージャーまたはシェル (未知の脆弱性が含まれている可能性がある) を含むイメージを使用しないようにします。あるいは、後でパッケージマネージャーを削除します。
不要なコンポーネントを追加しない：経験則として、一般的なツールをイメージに含めるとセキュリティリスクになる可能性があります。
最新のイメージのみを使用する：コンポーネントのバージョンをアップデートします。
イメージスキャナーを使用する：イメージ内の脆弱性を特定し、レイヤーごとに分類します。
CI/CD パイプラインにセキュリティを統合する：重大で修正可能な脆弱性が検知されたら継続的インテグレーションのビルドを失敗させてアラートを生成させるといった、繰り返し可能なセキュリティの側面を自動化します。
永続的な脆弱性にラベル付けをする：修正できない、重大ではない、またはすぐに修正する必要のない既知の脆弱性を許可リストに追加します。
多層防御を実装する：ポリシーチェックと修復ワークフローを標準化して、脆弱なイメージを検出および更新します。
デプロイ段階のセキュリティ
ワークロードをデプロイする前に、Kubernetes インフラストラクチャのセキュリティを構成します。それは、何がデプロイされているか (イメージ、コンポーネント、Pod)、どこにデプロイされているか (クラスタ、名前空間、ノード)、どのようにデプロイされているか (特権、通信ポリシー、適用されたセキュリティ)、何にアクセスできるか (シークレット、ボリューム) とそのコンプライアンス標準など、デプロイのプロセスについて可能な限り知ることから始まります。
名前空間を使用する：ワークロードを名前空間に分離すると、攻撃を封じ込めることができ、許可されたユーザーによるミスや破壊的なアクションの影響を制限できます。
ネットワークポリシーを使用する：Kubernetes のデフォルトではすべての Pod が他のすべての Pod に接続できますが、ネットワーク・セグメンテーション・ポリシーでそのデフォルトを上書きできます。
シークレットへの権限を制限する：デプロイメントに必要なシークレットのみをマウントします。
コンテナの特権を評価する：コンテナがその役割を果たすために必要な機能、ロール、特権のみを付与します。
イメージの出所を評価する：既知のレジストリから取得したイメージを使用します。
デプロイメントをスキャンする：スキャンの結果に基づいてポリシーを強制します。
ラベルとアノテーションを使用する：トリアージを効率化するために、コンテナ化されたアプリケーションを担当するチームの連絡先情報を使用して、デプロイメントにラベルまたはアノテーションを付けます。
ロールベースのアクセス制御 (RBAC) を有効にする：RBAC は、クラスタの Kubernetes API サーバーにアクセスするためのユーザーおよびサービスアカウントの承認を制御します。
ランタイム段階のセキュリティ
ビルドおよびデプロイメントの段階でプロアクティブなセキュリティアプローチを取ることで、ランタイムにセキュリティインシデントが生じる可能性を減らすことができますが、ランタイムの脅威を特定して対応するには、プロセスアクティビティとネットワーク通信を継続的に監視する必要があります。
コンテキスト情報を使用する：疑わしいアクティビティを検出するために、Kubernetes のビルドとデプロイの時間情報を使用して、ランタイムに実行予定のアクティビティと実際のアクティビティを評価します。
実行中のデプロイメントをスキャンする：コンテナイメージで最近発見されたものと同じ脆弱性について、実行中のデプロイメントを監視します。
組み込みの制御を使用する：Pod のセキュリティコンテキストを構成して、その機能を制限します。
ネットワークトラフィックを監視する：ライブのネットワークトラフィックを観察して、Kubernetes ネットワークポリシーで許可されているものと比較し、予期しない通信を特定します。
許可リストを使用する：アプリケーションのランタイムの通常の過程で実行されるプロセスを特定して、許可リストを作成します。
同様にデプロイされた Pod のランタイムのアクティビティを比較する：大幅な逸脱があるレプリカには調査が必要です。
疑わしい Pod をゼロにスケーリングする：Kubernetes のネイティブコントロールを使用して、疑わしい Pod をゼロにスケーリングするか、インスタンスを破棄して再起動するように Kubernetes に自動的に指示することで、侵害を封じ込めます。
Kubernetes インフラストラクチャのセキュリティ
セキュリティの対象は、イメージやワークロードだけではありません。セキュリティには、クラスタ、ノード、コンテナエンジン、さらにはクラウドなど、Kubernetes インフラストラクチャ全体が含まれます。
Kubernetes のアップデートを適用する：Kubernetes ディストリビューションをアップデートすると、セキュリティパッチが適用され、新しいセキュリティツールがインストールされます。
Kubernetes API サーバーを構成する：非認証アクセスや匿名アクセスを無効にし、kubelet と API サーバー間の接続に TLS 暗号化を使用します。
etcd を保護する： etcd は、Kubernetes がデータアクセスに使用する Key-Value ストアです。kubelet を保護しましょう。--anonymous-auth=false フラグを指定して kubelet を起動することにより、kubelet への匿名アクセスを無効にし、NodeRestriction アドミッション・コントローラーを使用して、kubelet がアクセスできるものを制限します。
クラウドセキュリティ
コンテナをホストする、または Kubernetes を実行するクラウドの種類 (パブリッククラウド、プライベートクラウド、ハイブリッドクラウド、またはマルチクラウド) に関係なく、次のような Kubernetes ワークロードを保護する責任は、クラウドプロバイダーではなく、常にクラウドユーザーにあります。
コンテナイメージ：ソース、コンテンツ、脆弱性
デプロイメント：ネットワークサービス、ストレージ、特権
構成管理：ロール、グループ、ロールバインディング、サービスアカウント
アプリケーション：シークレット管理、ラベル、アノテーション
ネットワーク・セグメンテーション：Kubernetes クラスタ内のネットワークポリシー
ランタイム：脅威の検出とインシデント対応
