Kubernetes とは?

Kubernetes (クバネティス、K8s としても知られる) は、コンテナ化されたアプリケーションのデプロイメント、拡張、管理を自動化します。 

オンプレミス、クラウド、ハイブリッド環境など、あらゆる場所のマシンのクラスタ全体でコンテナをオーケストレーションします。

Kubernetes は、インフラにレジリエンス、スケーラビリティ、セキュリティを組み込みます。 

ただし、Kubernetes は動的であり、その分散管理型アーキテクチャによって独特のセキュリティ上の複雑さが生じ、専門的な管理と継続的な可視化が必要となります。

それでもなお、Kubernetes はコンテナオーケストレーションのデファクトスタンダードなのです。 

マイクロサービスの管理、バッチジョブの実行、クラウドネイティブなアプリの構築など、どのような用途でも、Kubernetes はインフラを拡張しながら複雑さを制御するのに役立ちます。

Kubernetes を使用すると、分散型のインフラ全体でコンテナ化されたワークロードを実行できます。 これには、単純なウェブアプリケーションから複雑なマルチサービスプラットフォームまで、あらゆるものが含まれます。 

K8s によって、手動による設定を行わなくても、あらゆる環境にアプリケーションをデプロイして拡張できるようになります。

Kubernetes を使用すると、以下が可能になります。

• CI/CD ワークフローにおけるデプロイメントパイプラインの自動化
• 需要とリソースの使用状況に応じたマイクロサービスの拡張
• コンテナ密度の最適化によるインフラコストの管理
• ベンダーロックインなしの、ハイブリッド環境とマルチクラウド環境の運用
• 組み込みのフェイルオーバーと自己修復機能によるダウンタイムの削減

Kubernetes は最新のアプリケーション開発とセキュリティに広く採用されており、テクノロジースタックや、クラウドネイティブアプリケーションの構築と保護における重要なコンポーネントとなっています。

Kubernetes の利用をクラウドのリスク戦略と整合させたい場合は、 デプロイメントモデルのセキュリティを優先する方法をご確認ください。

Kubernetes クラスタは、Kubernetes の仕組みの基盤となるものです。 

K8s クラスタには次の内容が含まれます。

• 1 つのコントロールプレーン。ワークロードのスケジューリングやクラスタイベントへの応答など、グローバルな意思決定を行います。
• 1 つ以上のワーカーノード。コンテナを保持する Pod を実行します。

クラスタがあることで、一度デプロイすればどこでも同じように実行できるようになります。 

しかしクラスタは、特に API サーバーが公開されている場合や、ノードに過剰な権限が付与されている場合、ロールベースのアクセス制御 (RBAC) ルールが大まかすぎる場合などに、大体の設定ミスが起こる場所でもあります。 

このような設定上の問題を特定して修正するには、クラスタのデプロイメント状況やセキュリティ態勢を継続的に評価する必要があります。

2024 年 Tenable クラウドリスクレポートによると、78% の組織に一般アクセスが可能な Kubernetes API サーバーがあることが判明しています。 

数分もあれば、攻撃者がこうしたエクスポージャーを悪用し、クラウドインフラの探索を始めることが可能な場合もあります。

Kubernetes はモジュール式の分散管理型アーキテクチャを採用しています。 

アーキテクチャ内のコンポーネントは連携して働き、コンテナのオーケストレーションを行います。 

K8s の核となる構成要素には以下のようなものがあります。

• Pod: Kubernetes にデプロイ可能な最小単位
• サービス: クラスタ内外のトラフィックに Pod を公開する
• イングレス: サービスへの外部アクセスを管理する
• etcd: クラスタの設定と状態を保持するキーバリュー型ストア
• Kubelet: 各ノード上で動作し、コントロールプレーンと通信する
• Kube-scheduler および kube-controller-manager: ワークロード管理を自動化する

YAML 形式のマニフェストを使用すれば、宣言を使ってワークロードを拡張および更新し、環境の一部がオフラインの場合でも Kubernetes に望ましい状態を維持させることができます。

Kubernetes アーキテクチャは宣言的に自動化を実行することを可能にしますが、クラスタが拡大するにつれてアタックサーフェスも拡大する場所でもあります。

Kubernetes は、ワークロードの現在の状態を、設定ファイルで定義した望ましい状態と常に比較することで動作します。 

この 2 つが一致しない場合、差異を修正するための自動化されたアクションが実行されます。

たとえばノードに障害が発生した場合、Kubernetes は影響を受けた Pod を正常なノードにスケジューリングします。 

アプリケーションの新しいバージョンが利用可能になると、Kubernetes はローリングアップデートやブルーグリーンデプロイメントのような戦略を使って、ダウンタイムなしに更新を展開します。

Kubernetes は、モニタリング、ロギング、ポリシーのツールとも統合されます。 特に CI/CD パイプラインと組み合わせれば、シフトレフトのセキュリティに最適です。 開発およびデプロイメントのワークフローに直接セキュリティチェックを組み込むことで、問題があっても本番環境に取り込まれないように未然に防ぐことができます。

デプロイメント前にポリシーを適用したい場合は、 Tenable が開発ライフサイクルの各段階にセキュリティをどのように統合しているかをご覧ください。

コンテナは、軽量なスタンドアロンのソフトウェアパッケージであり、プロセスの実行に必要なあらゆるもの (コード、ランタイム、ライブラリ、依存関係など) が含まれます。 

Kubernetes では、コンテナは Pod 内で実行されます。Pod は、デプロイメントとネットワーキングのためにコンテナをグループ化するものです。

コンテナはワークロードをポータブルで一貫性のあるものにする反面、特に次のような場合に新たなリスクをもたらします。

• コンテナが特権モードで実行されており、ホストへの完全アクセスが可能になっている
• ワークロードのランタイム分離が不十分である
• コンテナが、検証されていないイメージをプルする

2024 年 Tenable クラウドリスクレポートによると、44% の組織が特権モードでコンテナを実行しています。 特に、攻撃者がすでに脆弱な API やサービスアカウントにアクセスできる場合は、権限昇格のリスクが大幅に高まります。

Docker と Kubernetes は、多くの環境で密接に連携しています。

Docker はコンテナエンジンです。 アプリケーションをパッケージ化し、それらをコンテナとして実行します。 

Kubernetes はコンテナオーケストレーションシステムです。 そのコンテナをクラスタ全体にデプロイし、管理します。

以前 Kubernetes は、そのランタイムとして Docker に依存していましたが、現在は Container Runtime Interface (CRI) を通じて、他のエンジン (containerd など) もサポートしています。

Kubernetes 1.24 以降、Kubernetes コミュニティとプロジェクトメンテナーは、Docker Engine のコンテナランタイムとしての直接統合を廃止しました。 現在の Kubernetes の最新バージョンは 1.33 です。

常に以下の項目を監視する必要があることにご注意ください。

• コンテナの過剰な権限
• API の設定ミス
• 未検証のイメージソース
• 古いランタイムコンポーネント

これらの相互に関連するリスクに対処するには、コンテナイメージレイヤーとオーケストレーションレイヤーの両方を含む一元的なビューが必要です。

Kubernetes を初めて使用するのであれば、最も手っ取り早い方法は、Minikube や kind でローカルクラスタをデプロイすることです。 

こういったツールは K8s をローカルで実行するので、本番環境にプッシュする前にデプロイメントをテストできます。

基本的なテスト手順は以下の通りです。

1. Minikube または kind をインストールします。
2. デプロイメントマニフェストを YAML で記述します。
3. kubectl を使用してデプロイメントを適用します。
4. アプリケーションをサービスとして公開します。
5. Pod を増やしたり減らしたりして実際の負荷をシミュレーションします。

このハンズオンワークフローを使用すると、Kubernetes がどのように Pod をスケジュールし、設定を適用し、障害に対応するかを確認できます。これは、大規模な自動化と、本番前の環境のセキュリティ確保のための基盤となります。

Kubernetes のセキュリティをテストする準備が整ったら、 Tenable Cloud Security のデモをお申込みください。

Kubernetes は強力ですが、コンテナを実行する唯一の方法ではありません。 

以下のような代替手段も利用できます。

• Docker Swarm: 単純なオーケストレーションに対応
• Nomad: さまざまなワークロードタイプの混合に対応
• K3s: 軽量の Kubernetes ディストリビューション
• マネージドサービス

それぞれの手段は、パフォーマンス、ポータビリティ、セキュリティにおいてトレードオフの関係にあります。 Kubernetes の複雑さを管理することが難しいようであれば、特に小規模なチームの場合、マネージドソリューションの方がユースケースに適しているかもしれません。ご検討ください。

Kubernetes における脆弱性の管理は、従来のイメージスキャンをはるかに超えたものになります。 

コンテナは 1 つのレイヤーに過ぎません。 Kubernetes のコントロールプレーン、クラスタ構成、ワークロードのランタイムの挙動は、すべて異なるリスクをもたらします。

ツールはコンテナイメージの CVE にフラグを立てることがありますが、多くの場合、過剰な cluster-admin バインディング、外部に露出した kubelet API、特権モードで実行されているワークロードを見逃してしまいます。 これらのリスクはまさに、攻撃者が権限を昇格させるために利用するものです。

Kubernetes の完全な脆弱性管理戦略には以下が含まれます。

• クラスタ全体にわたるリアルタイムの可視性
  • Kubernetes のワークロードは多くの場合、一時的なものです。 Pod は、起動しては数秒で姿を消してしまいます。 脆弱性スキャナーを Kubernetes 環境に直接統合しなければ、重大なリスクを見逃す可能性があります。
  • Kubernetes ネイティブのアプローチによって、静的な設定と動的な稼働中のワークロードの両方を継続的に可視化できます。
• 複数のレイヤーでの継続的なスキャン
  • アプリケーションコードをスキャンするだけでなく、 以下について評価します。
    • ベースイメージの脆弱性
    • ランタイムの設定ミス
    • コントロールプレーンのコンポーネント (etcd、API サーバーなど)
    • RBAC ルールとサービスアカウントトークン
    • 信頼できるベンチマークを使用したポリシーの適用
• CIS Kubernetes Benchmark や Pod Security Standards のようなフレームワークによるセキュリティチェック
  • これらによって、開発から本番環境までの一貫した脆弱性対策のために、環境全体にガードレールが確立されます。
• CI/CD 統合によるシフトレフト
  • 最新の Kubernetes 環境は自動化されています。 脆弱性チェックも同様に自動化されるべきです。 Tenable は、CI/CD パイプラインにセキュリティを統合することで、設定ミスの YAML ファイル、脆弱なイメージ、または過剰な権限が付与された設定を、クラスタに到達する前にブロックできます。
• リスクベースの優先順位付け
  • Tenable Cloud Security などのツールは、設定上の欠陥を、アクティブなネットワークエクスポージャーや潜在的な攻撃経路と関連付けることにより、実際に稼働中の環境に基づいてリスクをスコアリングします。 つまり、隔離されたコンテナ内の深刻度の低い CVE よりも、アクティブなエクスポージャーが存在する既知のエクスプロイト経路を優先するということです。

Kubernetes における脆弱性管理では、コードと同様に構成管理も重要です。クラスタの実際の動作に合わせて調整されたプラットフォームが必要です。実際のクラスタの挙動に合った、静的な解析とリアルタイムの稼働に関する文脈情報と修正ガイダンスを組み合わせたプラットフォームが必要です。

Kubernetes の脆弱性管理の運用をお考えであれば、 Tenable が一元的な可視性とリスクベースの優先順位付けをどのように実現しているかをご覧ください。

Kubernetes を環境全体で使うように拡張すると、アタックサーフェスも拡大します。 

クラスタは動的なものであり、 Pod、名前空間、サービスは常に変化します。 

一元的な可視性がなければ、エクスポージャーを完全に把握することはほぼ不可能です。

Kubernetes におけるエクスポージャー管理は、攻撃者が最初にアクセスできる場所を特定することから始まります。 

2024 年 Tenable クラウドリスクレポートによると、Kubernetes API サーバーをパブリックインターネットに公開している 78% の組織のうち、41% がインバウンドアクセスを許可しています。 

こうした公開が意図的に行われることは滅多にないのですが、攻撃者はまさにそれらを悪用するのです。

Kubernetes は、以下のような固有のエクスポージャーレイヤーを生み出します。

• アクセス制御が脆弱、または欠如している、公開された API サーバー
• 外部トラフィックを内部サービスに転送してしまう、設定ミスのあるイングレスコントローラー
• 信頼境界線を拡大してしまう、system:authenticated のように長年非常に多くのユーザーによって使われてきたパブリックグループ
• ほとんどセグメント化されていない、Pod とノード間のオープンな内部トラフィックパス

従来のツールを使用していると、こうした問題を見つけるのは困難です。そのため、Kubernetes のエクスポージャー管理は、インフラレイヤーとオーケストレーションレイヤーの両方に対する可視性に大きく依存しています。

Kubernetes クラスタをどのように設定したか、ワークロードをどこに公開したか、ネットワークポリシーによりどのようにリスクを低減または増幅されたかを確認する必要があります。 

静的なリソースをスキャンするだけでは不十分です。 クラスタの拡張やワークロードの変化に応じて新たなエクスポージャーを継続的にマッピングする、文脈を考慮した検出も必要です。 これにより、外部へのエクスポージャーから内部リソースの脆弱性に至る潜在的な攻撃経路のインサイトを得ることができます。

効果的なツールであれば、Kubernetes API と直接統合され、ポリシー違反を監視し、過剰に権限が付与されたロールと到達可能な API エンドポイントのような危険な組み合わせにフラグを立てることができます。

本番環境でコンテナを運用している方ならば、すべてを安全に保とうとする難しさを痛感していることでしょう。 

Kubernetes は強力ですが、すぐに厄介なことになりがちです。 

前の日は順調だったのに、ある日突然、誰かに、Pod の権限が多すぎるとか、ネットワークポリシーにトラックでも通れるような穴があるとかを指摘されることがあります。

要するに、これこそが Kubernetes セキュリティポスチャー管理が存在する理由なのです。 

KSPM がなければ、通常は以下のようになります。

• 開発者はスピード重視で、新しいサービスを次々と立ち上げ、設定を微調整する
• セキュリティのチェックはスキップ、するとしても後回しになる
• その間に、設定ミスが積み重なり、無害なものもあるが、攻撃者などに見つかればニュースの見出しを飾るような事態を招くようなものもある

KSPM ならこの流れを覆せます。 

事が起きてからセキュリティを適用するのではなく、クラスタで実際に何が起きているかを継続的に確認できす。 

セキュリティの専門家に絶えず見守ってもらうような安心感が得られると言えるでしょう。人が後ろに立って監視されているような気まずい圧迫感ではありません。

KSPM のプロセス

まず、KSPM は、ユーザーが把握していないアプリやサービスも含めて、実際に稼働しているものを見つけ出します。 

そして、実際の設定を、セキュリティのベストプラクティスや内部ルールと比較します。 

このツールが賢いのは、検出結果に優先順位を付けられるところです。 すべての設定ミスが重大な問題とは限らないため、実際に重大な問題に集中できるよう支援します。

優れた KSPM ツールは、セキュリティの問題がなぜ危険なのか、それに対して何をすべきかを理解するのに役立ちます。 

さらに、対応状況が時間の経過とともに本当に改善しているのか、それとも足踏みしているだけなのかも追跡できます。

これは、クラウドセキュリティポスチャー管理 (CSPM) のような通常のクラウドセキュリティツールとは異なります。 これらのツールは、IAM ロールやネットワーク設定など、より広範な AWS や Azure の設定を調査するものです。 

KSPM は、Kubernetes に対してきめ細かく対応します。Pod 同士がどのように通信するのか、クラスタレベルのポリシーが何を意味するのか、Kubernetes の予想外の動作を把握します。

KSPM ソリューションを探す際は、あらゆる場所にエージェントをインストールする必要があるものは避けてください。 個別のパーツを今まで以上増やす理由はありません。

回避策を強いるソリューションではなく、お使いのワークフローと統合する KSPM プラットフォームをお探しください。

KSPM が通常の開発プロセスの一部になれば、真の成果が得られます。 

セキュリティが後から別の部門でチェックされるのではなく、開発者はプルリクエストで即座にフィードバックを受け取れるのです。 

現実問題として、コンテナセキュリティの必要性がなくなることはありません。 むしろ、こうした環境が拡大するにつれて、より複雑になっていきます。 

できるのは、KSPM のようなものを使用して先んじて対応するか、何か問題が起こるたびに対応するイタチごっこをするのかのどちらかです。

簡単に言うと、Kubernetes とは何ですか?
Kubernetes は簡単に言うと、コンテナでのアプリケーションの実行を自動化するプラットフォームです。 K8s とも呼ばれる Kubernetes は、クラウドやオンプレミスのシステム全体でコンテナを拡張、管理するのに役立ちます。

Kubernetes は Docker なしでも実行できますか?
はい、Kubernetes は Docker なしでも実行可能です。 デフォルトで containerd や他のランタイムを使うようになったので、 Docker はもはや必須の依存関係ではありません。

コンテナと Kubernetes の違いは何ですか?
コンテナはコードをパッケージ化します。 Kubernetes は、そういったコンテナがどこで、どのように実行されるのかを管理します。

Kubernetes の習得は難しいですか?
Kubernetes の習得は最初は敷居が高く感じられるかもしれませんが、Minikube のようなツールやチュートリアルを使えばすぐに使い始めることができます。

Kubernetes は Windows で動作しますか?
はい、Docker Desktop や WSL 2 などのツールを使うと、Windows 上で Kubernetes を実行できます。

Kubernetes はスケーラビリティと自動化を実現しますが、それは適切に設定し、セキュリティを確保した場合に限られます。 RBAC、ネットワークポリシー、またはランタイム権限に誤りがあると、ビジネスを深刻な脅威にさらす可能性があります。

Kubernetes のセキュリティを安心して簡略化できる、Tenable Cloud Security から始めましょう。