Kubernetes セキュリティ

Kubernetes (k8s) セキュリティとは？

K8sは非常に有名な コンテナオーケストレーションプラットフォームのひとつで、多彩な機能を備えています。持ち運びやすく、拡張性にも優れているため、その普及に伴いDevOpsチームはクラスター、K8s API、コンテナなどのデジタルセキュリティ基準を強化せざるを得なくなっています。

セキュリティの弱さから約55％のプロジェクトが遅延している現状を背景に、K8sユーザーの98％が年に一度以上のセキュリティトラブルに直面していると回答しています。

K8sを守るとは、K8sで開発されるアプリが万全でサイバー攻撃に強い状態であるよう、複数の手法を組み合わせるプロセスです。

Kubernetesのセキュリティは、以下で説明する4Cに基づいています。

• クラウド、コロケーション施設、企業データセンター

K8sセキュリティの基盤は、クラスター運用に使用されるインフラや環境です。クラウドやデータセンターを用いるため、プラットフォームの基本設定を守る最良かつ実績のある手法を採用する必要があります。

• クラスター

クラスターはK8sの重要な構成要素であり、そのセキュリティはクラスター上のアプリとK8s API全体を対象とすべきです。

• コード

保護されていないコードは攻撃の経路となり、サイバー攻撃者がK8sのリソースやアプリに悪影響を及ぼす恐れがあります。したがって、TLS暗号化、認証、未使用ポートの無効化、定期的なコードスキャンなどの適切な手法を導入する必要があります。

• コンテナ

コンテナの設計の完成度は、将来のK8sセキュリティの範囲を左右します。最小限のコードベースから設計を始め、コンテナを継続的にスキャンすることが求められます。

コンテナのライフサイクルにおいてK8sセキュリティが重要な理由

K8sクラスターはコンテナベースのアプリ開発に有用ですが、その動的な特性と分散構造は、複数のセキュリティ課題を生み出します。クラスターごとに異なるソリューションが必要なため、ひとつの標準的な手法では対応できません。

変化する実行環境では、各podが移動中も守られるよう、ITやDevOpsチームに大きな課題が生じます。このため、K8sセキュリティは徹底して対策する必要があります。

‍

Kubernetes セキュリティの課題

• ビルド時の主な脆弱性

デジタルソリューションの構築およびリリース前に、主に二つの問題が発生する可能性があります。

まず一つ目は、認証されていないレジストリからコードを使用することです。開発者が意図的に、あるいは知らずに不正なコードを利用すると、マルウェアやウイルスの侵入口となり得ます。

次に、不要に膨らんだベースイメージが問題となります。コンテナ化されたアプリは保持できる容量が限られているため、イメージの最適化を優先すべきです。リソースの使用量が増えるほど、リスクは高まります。

• デプロイ時の主な抜け穴

開発段階でよく見られる問題として、過剰な権限の付与、複数クラスターの分離不足、アプリ内でのクラスター間の横展開、不正アクセスの許可が挙げられます。

• 実行時の主な脅威・リスク

アプリが実行段階に入ると、インフラへの攻撃や複雑なクラスター構成が、主要なK8sセキュリティ課題となります。

Kubernetes セキュリティのベストプラクティス

確固たるKubernetesネットワークセキュリティの確保は、すべてのK8sユーザーの重要な責務です。これを怠ると、データ漏洩、マルウェア攻撃、不正なコード使用など様々な問題に発展します。

Kubernetesコンテナセキュリティに深く関与する場合、開発段階ごとに以下の主要なプラクティスを守ることが推奨されます。

ビルド段階

アプリ開発の大部分はビルドまたは開発段階で行われます。この段階でコード、クラスター、コンテナをしっかり守ることで、完成度の高いアプリが実現できます。

以下は、好まれるSDLC段階でのK8sセキュリティプラクティスの例です：

1. イメージスキャン

コンテナイメージはコンテナ化アプリ開発において重要な役割を果たします。多くの機能を担うため、脆弱性がないことが重要です。

自動化ツールによるイメージスキャンで、隠れた脆弱性を開発前に発見できます。

このプラクティスを採用する際は、すべてのCI/CDパイプラインでイメージスキャンを実施し、改ざんの可能性がないか確認する必要があります。

2. ホストOSの強化

コンテナには必要最低限の権限のみを与えることが大切です。システムコールやファイルアクセスを十分に制御できる、強化されたOSを利用することで、権限昇格攻撃を防ぎ不要なアクセスを排除できます。

3. 攻撃面の最小化：基本コンテナイメージ

理想的なコンテナベースイメージは、必要なソフトウェアパッケージが最小限であるものです。これにより、攻撃面を削減できます。適切なイメージが存在しない場合は、Docker From Scratchの指示に従って自作するか、LinuxディストリビューションやAlpineの最小イメージを利用することが可能です。

展開段階

脆弱性のないアプリが開発されたとしても、展開段階で問題が発生する可能性があります。したがって、以下のプラクティスを採用する必要があります。

1. セキュリティツールのKubernetesクラスターへの統合

すべてのセキュリティツールがK8sに対応しているわけではありません。NGFWやウェブアクセス制御ゲートウェイが稼働しているだけでは十分ではなく、これらをK8sクラスターと統合し、セキュリティシステムのカバー範囲を広げ、脆弱性を迅速に発見できるようにする必要があります。

一つの方法として、ワークフローのTCP/UDPポートやIPアドレス情報をセキュリティツールの対象範囲に登録し、連携するK8sリソースの検出を許可する手法が挙げられます。

また、セキュリティグループを利用してK8sノードのネットワーク接続を制限することで、K8sアーキテクチャに沿った管理が可能になります。

2. Kubernetesクラスターの強化

初期状態のK8sクラスター構成は脆弱なため、強化が必須です。設定レビューを実施して欠陥を洗い出し、Kube-benchなどのツールを用いれば自動かつ効果的に改善できます。

また、各構成要素の信頼モデルを構築することで、クラスターの応答を制御できます。タクソノミーやラベル管理を活用することが重要です。

Role Based Access Control (RBAC)を利用すれば、アクセス制御を強化し、脅威モデルに沿った運用が可能となります。

実行段階

最後の実行段階では、アプリが常に正常に動作するよう、完璧な状態を維持する必要があります。以下のプラクティスを守ることで、脆弱性のない実行環境を実現できます。

1. ネットワークセキュリティ制御

企業向けネットワークセキュリティは通常、ノード単位の通信のみを管理するため、実行時に問題が発生する可能性があります。一般的に、ノード間の往復通信のみの制御となり、どのサービスやノードが動作しているか特定するのは困難です。

これが基本的な実行時の脆弱性です。

Kubernetesのワークロードは動的であり、既存サービスの新バージョンが次々と登場するため、セキュリティ制御の管理は一層難しくなります。

ネットワーク固有の制御を強化するには、ワークロード内でセキュリティ定義を設定するのが望ましく、宣言的モデルが大いに役立ちます。

また、セキュリティ定義はワークロードの重要な部分として、データセンターやK8sディストリビューションから容易に参照できるようにし、K8sネットワークポリシーツールやKubernetesネイティブプロキシの利用が有効です。

2. エンタープライズセキュリティ制御

ネットワークセキュリティ制御単独では十分ではなく、エンタープライズセキュリティ制御と組み合わせる必要があります。例えば、データ転送時の暗号化、自動コンプライアンスレポートの生成、継続的なコンプライアンスの確保が推奨されます。

3. 脅威防御

攻撃者はK8sクラスターに侵入し、悪意ある内容を仕込む可能性があります。成功すれば、実行時にマルウェアが挿入されたりクラスター構成が改ざんされたりするリスクがあり、いずれも有害です。

したがって、DevOpsチームは効果的な侵入検知と防止機能を備えた、実効性のある脅威防御システムを整備する必要があります。

このシステムはデータ解析による異常検知と、有害な行動の遮断機能を持つことが求められます。膨大なデータを扱うため、podごとに集約し自動解析ツールの利用や、IPアドレスおよびドメインの継続監視を行うことが推奨されます。

‍

その他のベストプラクティス

Kubernetesセキュリティは幅広い分野を包含し、他の対策も必要です。リスク軽減のため、以下の主要なK8sプラクティスを活用できます。

1. PodSecurityPolicy (PSP)

PodSecurityPolicy (PSP)は、pod設定のセキュリティ課題を解決するための機能豊富なオブジェクトです。有効化すると、各podがクラスターに参加する前に守るべき最低限のセキュリティ要件が定義されます。

ただし、このプラクティスは使い勝手が良いとは言えず、いくつかの制約があり、単独で有効化することはできません。

2. ネットワークポリシー

ネットワークポリシーは、各podに対する仮想ファイアウォールのようなもので、ネットワーク管理者が定義します。これにより、pod同士の通信方法を指示でき、podレベルで自動的に有効化され、podはポリシーを受け入れるか拒否する権限を持ちます。

3. Kubernetes RBAC

Kubernetesは、ユーザーがクラスターや対象namespace内で実行できる操作を定義するため、あらかじめRoleやClusterRoleの概念を定めています。

ClusterRoleBindingを使用すると、すべてのリソースに特定のロールを適用でき、RoleBindingを用いればnamespace単位でロールを設定できます。これにより、クラスターやnamespaceが定義された基準を超えた利用を防止できます。

4. Kubernetes Ingress 用TLS

K8s IngressにTLSを適用することは、Kubernetesセキュリティを向上させる簡単な方法です。

Ingressは、外部から特定のK8sクラスターへアクセスする際に使用され、HTTP/S接続でルーティングルールが設定されます。

tls.crtやtls.keyを使用することで、クラスター内の通信がより暗号化されます。

5. Quality of Service (QoS)

QoSは、各クラスターやpodに自動適用されるKubernetesの定番セキュリティプラクティスです。これにより、スケジューリングやpodのエヴィクションが最適化され、各podごとにカスタマイズルールを設定できる点が大きな利点です。

6. 認証

Kubernetes認証は、K8s APIを守るための推奨手法です。通常、APIはTLSで保護されポート445でアクセスされますが、これだけでは十分とは言えません。認証を導入することで、未承認の利用を防止できます。

7. Kubernetes Secrets

Kubernetes Secretsは、K8sに標準搭載されている機能で、重要なデータを安全に保管するために利用されます。パスワードやSSH鍵をプレーンテキスト、もしくはpod設定やコンテナイメージ内に保存することは推奨されず、これにより攻撃者に情報を突かれるリスクがあるためです。

Secretsとして情報を管理することで、データを守り、不正アクセスの発生を抑制できます。

‍

Kubernetesを守るWallarmのソリューション

Wallarmは、K8sセキュリティを強化しリスクを抑えるための最先端APIセキュリティプラットフォームです。以下のソリューションが含まれます。

• WAF

WAF（Web Application Firewall）は、ウェブアプリを守るための定番ツールです。WallarmのクラウドWAFは最先端で、主要なクラウド環境やAPIに対応しており、SOC2やPCI DSSの基準を満たしています。ラインの自動調整、初期段階でのゼロ偽陽性、複数のDevOpsツールやSIEMとの統合、ワンクリックインストールといった機能により、理想的なKubernetes APIセキュリティツールとして高く評価されています。

• API Security Platform

WallarmのAPI Security Platformは、マルウェア挿入、不正利用、過剰使用などのAPI脅威を防ぐための最速の手段です。既存のDevOps環境と連携し、初期段階からAPIを強化します。

このツールは、APIの変化を即時に把握し、APIやアプリのトポロジーを調整し、機微なデータ利用を検知する点で高く評価されています。その効果的な利用により、OWASP Top 10リスク、有害ボット、API特有の脅威を抑制でき、脅威対応時間の短縮、異常なリクエストの検知、即時の警報・通知を実現します。

また、開発者が脅威を発見し、対策を講じ、今後の保護策をあらゆるAPI、マイクロサービス、コンテナに適用するのに役立ち、WallarmはAPI保護のための技術支援と展開支援を提供しています。