Kubernetes セキュリティとは

URL をコピー

Kubernetes (K8s または「kube」とも呼ばれる) はオープンソースのコンテナ・オーケストレーション・プラットフォームで、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを自動化します。Kubernetes は、Linux コンテナをクラスタにまとめ、アプリケーション・プログラミング・インタフェース (API) を使ってコンテナ化されたマイクロサービスを接続します。Kubernetes のデプロイメントに関わるあらゆるレイヤーやサービスに脆弱性が存在する可能性があるため、Kubernetes クラスタのセキュリティ確保のプロセスは複雑なものになりかねません。 

Kubernetes セキュリティに対して、コンテナイメージとコンテナランタイムのセキュリティに主眼を置いたコンテナ中心のアプローチを取るチームもあれば、Kubernetes からコンテキストを取り込み、Kubernetes の組み込みの制御を使用して、アプリケーション開発のライフサイクル全体でセキュリティに関するリスクベースのベストプラクティスを実装するという広範なアプローチを取る、Kubernetes ネイティブセキュリティを選択するチームもあります。Kubernetes ネイティブセキュリティは、Kubernetes RBAC ポリシーの設定ミス、安全でない Kubernetes コントロールプレーン・コンポーネント、Kubernetes シークレットの誤用など、Kubernetes 特有のリスクや脆弱性にも対処します。

Kubernetes は、比較的新しいテクノロジーとして近年非常に多く導入されていますが、セキュリティへの投資は必ずしも追いついていません。セキュリティに対する意識の低さや、常に存在するスキルギャップと相まって、セキュリティインシデントは壊滅的な結果をもたらす可能性があります。セキュリティの問題は、アプリケーションの開発やデプロイメントの遅延や速度の低下の原因となっています。インシデントに発展した場合、Kubernetes とコンテナのセキュリティ問題は、収益や顧客の損失、従業員の解雇をはじめとする、事業運営上のあらゆる影響をもたらします。

Kubernetes とコンテナ化は、より迅速でスケーラブルな DevOps を促進しますが、そこにはさらなるセキュリティリスクも伴います。コンテナのデプロイメントが進むにつれて攻撃対象が拡大し、どのコンテナに脆弱性や設定ミスがあるのかをピンポイントで特定することが難しくなります。

共通のリスクと課題

Kubernetes の Pod 間ネットワーキング

Kubernetes の主要なメリットの 1 つに、クラスタ内の Pod の通信方法を制御する幅広いネットワーク設定オプションが挙げられます。しかし Kubernetes はデフォルトではクラスタ内の Pod 間ネットワーク通信を制限しないため、関連するネットワークポリシーが割り当てられるまではすべての Pod が他の Pod と通信できます。つまり、1 つの Pod が悪意ある攻撃者に侵害されると、その Pod がクラスタ内の他のすべての Pod を攻撃するためのベクトルとして使われる可能性があるということです。Kubernetes のネットワークポリシーは、YAML ファイルを使って記述します。このことは Kubernetes のネットワークポリシーの運用が難しい理由の 1 つであり、スピードを優先してネットワーク・セグメンテーションを見送ってしまう場合もあるでしょう。 

構成管理

人為的なミスや自動セキュリティスキャンの欠如によって引き起こされることの多い構成ミスは、Kubernetes 環境に深刻なリスクをもたらすうえ、侵害につながることもあります。コンテナは動的な性質を持っているため、構成ミスを特定し、一貫したセキュリティ体制を維持することは容易ではありません。Kubernetes はスピードと操作性を優先して開発されたものであるため、デフォルトの設定はオープン/無制限が一般的です。この設定により、組織は攻撃を受けやすくなります。

ソフトウェア・サプライチェーンの問題

ソフトウェア・サプライチェーンのセキュリティ問題 (脆弱なアプリケーション・コンポーネント、不十分なアクセス制御、ソフトウェアの部品表 (SBOM) の欠如、CI/CD パイプラインの弱点、一貫性のないポリシー実施など) は、組織にとっても大きな懸念事項です。クラウドネイティブや Kubernetes 環境に象徴されるように、ソフトウェア・サプライチェーンは広大であり、独自の管理体制が必要です。ソフトウェア・サプライチェーンのセキュリティは、個別の開発環境 (IDE) から始まり、ランタイム環境にまで及ぶ必要があります。サプライチェーンに関わるすべてのコンテンツ (ソースコード、画像、アーティファクト)、ツール (開発者、セキュリティ)、そして人を考慮する必要があります。ソースコード解析、アクセス制御、証明、SBOM は、ソフトウェア・サプライチェーンのセキュリティのための膨大なセキュリティ検討事項のほんの一部に過ぎません。 

セキュリティを左にシフトする

ソフトウェア・サプライチェーンのセキュリティと密接な関係にあるのが、セキュリティを左にシフトするという課題です。「セキュリティを左にシフトする」とは、つまり Kubernetes のセキュリティへの取り組みをコンテナライフサイクルの初期段階に移すべきだという考え方です。セキュリティを早期に取り入れるには、開発者がセキュリティユーザーとなり、ワークフローの中でセキュリティに関する意思決定を行うための知識とツールを身につけることが必要となるため、簡単なことではありません。しかし、セキュリティを早期に取り入れることによるビジネス上のメリットは多大です。これこそ、Kubernetes とコンテナのセキュリティを実装するための主要手段と言えるでしょう。構築段階で多くのセキュリティ問題が解決されれば、ランタイムの問題が減少し、プロジェクトの遅延が少なくなります。

ランタイムの検出と対応

Kubernetes 環境で実行されるコンテナ化アプリケーションに存在するランタイムの脅威ベクトルのボリュームは、このような問題の検出と対応を担当するチームにとって課題となっています。悪意ある攻撃者が Kubernetes 環境に初期アクセスし、悪質なコードを実行して権限を昇格させ、永続性を獲得し、検出を回避し、横方向に移動してデータの削除や流出、サービス拒否、リソースハイジャックを引き起こす方法は数多く存在します。このトピックについては、Kubernetes 向けの MITRE ATT&CK® フレームワークに関するブログでさらに詳しく解説しています。 

Kubernetes インフラストラクチャのセキュリティ

API サーバー、kube-scheduler、kube-controller-manager、etcd といったコントロールプレーン・コンポーネントから、コンテナ化されたワークロードを実行するワーカーノード・コンポーネントまで、Kubernetes の多くの層には独自のセキュリティ課題があります。アプリケーションを実行するための強化されたクラスタ環境を提供するために、これらのサービスはそれぞれ安全に設定されなければなりません。さらに、Kubernetes をセルフマネージド型サービスとして運用するか、フルマネージド型のクラウドサービスを利用するかによって、Kubernetes のさまざまなコンポーネントをどのように保護しなければならないかが変わってきます。例えばセルフマネージドの環境では、多くの場合、ノード・コンポーネントに加えてコントロールプレーン・コンポーネント全体の管理もご自身の責任で行う必要があります。マネージド Kubernetes サービスを利用する場合、セキュリティの責任はサービスプロバイダーとお客様との間で共有されます。これによりさらなる課題が生まれます。

コンテナ化と Kubernetes には、コンテナセキュリティの問題に関連するリスクの対処に役立つセキュリティ上の利点が複数組み込まれています。以下に例を示します。

  • ランタイムで発見されたセキュリティ問題を含むコンテナは、稼働中にアップデートやパッチが適用されるのではなく、構築段階で修正されて再デプロイされます。不変性と呼ばれるこの特長は、コンテナの挙動をより予測しやすくし、異常な動作を検知できるようにします。 
  • ネットワークポリシーで Pod や Pod のグループをセグメント化し、アドミッション・コントローラーでポリシーを適用することで、ガバナンスを強化します。 
  • ロールベースのアクセス制御 (RBAC) によって、ユーザーやサービスアカウントに特定の権限を割り当てることができます。
  • Kubernetes シークレットは、暗号化キーのような機密データをより安全に保護することができます。

しかし、Kubernetes はセキュリティ・プラットフォームではないため、チームはリスク評価を運用し、Kubernetes 環境の各レイヤーおよびコンテナとアプリケーションのライフサイクル全体のあらゆる段階で、脆弱性に対処する必要があります。Kubernetes のセキュリティを効果的に行うには、ビルド、デプロイ、ランタイムの各フェーズでベストプラクティスを実施しつつ、利用可能な場合は Kubernetes ネイティブのセキュリティ制御を活用する必要があります。

 

オープンソース・コンテナ・テクノロジーのリーダーである Red Hat は、お客様が Kubernetes セキュリティのベストプラクティスに関する知識を深め、コンテナの実装をより安全なものにするお手伝いをします。チームが K8s のセキュリティに関する懸念をより効率的に特定して対処できるように、Red Hat は、コンテナのライフサイクルにセキュリティを組み込み、DevOps チームがプロダクション対応のアプリケーションを構築およびデプロイできるようにする Kubernetes ネイティブのソリューションを提供します。

StackRox が作成し、2021 年に Red Hat が買収した KubeLinter は、Kubernetes デプロイメントの構成ミスとプログラミングエラーを特定する、オープンソースの静的解析ツールです。KubeLinter は一連のテストを実行して、Kubernetes の設定を分析し、エラーを特定し、セキュリティのベストプラクティスに沿わないものに対して警告を生成します。 

Red Hat Service Interconnect は、デフォルトでクラスタやクラウド全体でスケーリング可能な組み込みのセキュリティを備え、サービス間の信頼できる通信リンクを提供します。また、Service Interconnect はレガシー、コンテナ、Kubernetes プラットフォーム全体での柔軟な開発を可能にし、開発者に次世代のビジネスアプリケーションの構築、モダナイゼーション、デプロイメントに関する選択肢を提供します。

Red Hat® Advanced Cluster Security for Kubernetes (ACS) は、クラウドネイティブ・アプリケーションの構築、デプロイ、実行をより安全に行えるようにします。ACS は、セルフマネージド型またはフルマネージド型の SaaS ソリューションとして提供されます。主要なクラウドおよびハイブリッド環境で、コンテナ化されたワークロードを保護し、DevOps および InfoSec チームがセキュリティの運用、運用コストの削減、開発者の生産性の向上を実現できるようにします。

関連資料

記事

ステートフルとステートレス

あるものがステートフルかステートレスかは、別の何かとの通信の状態が記録される期間と、その情報をどのように保存する必要があるかによって決まります。

記事

Quarkus とは

Quarkus は、Java 仮想マシン (JVM) およびネイティブコンパイルのために作成された Kubernetes ネイティブの Java スタックで、Java をコンテナに最適化します。

記事

サーバーレスとは

サーバーレスは、開発者がサーバーを管理する必要なくアプリケーションを構築および実行できるようにするクラウドネイティブ開発モデルです。

クラウドネイティブ・アプリケーションの詳細はこちら

製品

統合されたテスト済みのサービス一式を備えたエンタープライズ・アプリケーション・プラットフォームであり、ユーザーの選ぶインフラストラクチャを使ってアプリケーションを市場に投入するために活用できます。

リソース

トレーニング

無料のトレーニング

Developing Cloud-Native Applications with Microservices Architectures