Kubernetesのセキュリティを向上させる6つの方法

この記事は10部構成の一部です。

1. Reduce Complexity with Production-Grade Kubernetes（英語）
2. 高度なトラフィック管理でKubernetesの耐障害性を向上させる方法
3. Kubernetesの可視性を向上させる方法
4. トラフィック管理ツールを使ってKubernetesを安全にする6つの方法（この記事です）
5. Ingressコントローラーの選択ガイド, Part 1: 要件の特定
6. Ingress Controllerの選択ガイド, Part 2 : リスクと将来性
7. Ingress Controllerの選び方ガイド, Part 3：オープンソース / デフォルト / 商用版
8. Ingress Controllerの選択ガイド, Part 4 : NGINX Ingress Controllerのオプション
9. サービスメッシュの選び方
10. Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment（英語）

これらのブログ一式を無料のebookとして下記よりダウンロードいただけます。–Kubernetes のテスト環境から本番環境への移行

「スピードを落とさずにクラウドネイティブアプリをセキュアにする」で説明したように、クラウドネイティブアプリを従来のアプリよりも安全にするのが難しくなる3つの要因が観察されています。

1. クラウドネイティブアプリの提供は、ツールの乱立を招き、エンタープライズグレードのサービスとして十分な一貫性が提供できない場合があります。
2. クラウドネイティブアプリの提供コストは、予測不可能で高額になる可能性があります。
3. SecOpsチームはクラウドネイティブアプリの保護に苦労しており、DevOpsと対立しています。

この3つの要素はすべて等しくセキュリティに影響を与えますが、3つ目の要素は、おそらく最も「人間的」であるため、解決が最も困難な問題になり得ます。SecOpsがクラウド・ネイティブ・アプリケーションを保護できない、あるいは保護する権限がない場合、いくつかの結果は明らかですが（脆弱性や侵入）、その他の結果は、アジリティの低下やデジタルトランスフォーメーションの停滞など、目に見えないものです。

その隠れたコストを深掘りしてみましょう。組織は、敏捷性とコスト削減を約束してくれるKubernetesを選択します。しかし、Kubernetes環境でセキュリティインシデントが発生すると、ほとんどの組織はKubernetesのデプロイメントを本番環境から撤退させます。それは、組織の将来にとって不可欠なデジタルトランスフォーメーションの取り組みを遅らせることになり、そしてエンジニアリングの努力と資金が無駄になることは、それ以降気にもとめられません。論理的に導き出した結論は、Kubernetesをテストから本番に移行させようとするならば、セキュリティは組織内の全員が所有する戦略的要素であると考える必要がある、ということです。

この記事では、Kubernetesのトラフィックを制御するツールで解決できる6つのセキュリティユースケースを取り上げ、SecOpsがDevOpsやNetOpsと連携して、クラウドネイティブアプリやAPIをよりよく保護できる手法を紹介します。これらの手法の組み合わせは、顧客への影響を最小限に抑えながらアプリやAPIを安全に保つように設計された包括的なセキュリティ戦略を作成するためによく用いられるものです。

1. CVEを迅速に解決し、サイバー攻撃を回避
2. OWASP Top10やDoS攻撃を阻止
3. アプリからの認証・認可のオフロード
4. 適切な権限管理によるセルフサービスの設定
5. エンドツーエンドの暗号化の実装
6. クライアントが信頼できる実装で強力な暗号を使用していることを確認

セキュリティとアイデンティティの専門用語

ユースケースに入る前に、この記事で出てくるセキュリティとアイデンティティに関する用語の概要を説明します。

• 認証と認可 – 「正しい」ユーザーとサービスだけがバックエンドやアプリケーション・コンポーネントにアクセスできることを保証するために必要な機能です。:

  • 認証 – リクエストを行うクライアントが本人であることを確認するためのアイデンティティの検証です。パスワードやJSON Web Token(JWTs)などのIDトークンによって達成されます。

  • 認可 – リソースまたは機能へのアクセス許可の検証です。セッション・クッキー、セッション ID、グループ ID、トークン・コンテンツのようなレイヤ 7 の属性など、アクセストークンを通じて達成されます。

• CVEs（Critical Vulnerabilities and Exposures） – 一般に公開された不具合に関するデータベースで、「ソフトウェア、ファームウェア、 ハードウェア、サービスコンポーネントにおいて、悪用されると影響を受けるコンポーネントまたはコンポーネントの機密性、完全性、可用性に悪影響を与える可能性がある」ものです（https://www.cve.org/）。CVE は、ツールを管理する開発者、侵入テスト担当者、ユーザーや顧客、コミュニティの誰か（「バグハンター」のような人）により発見されるかもしれません。悪意ある行動をとる者に優位性を与えないようにするため、脆弱性が公表される前に、ソフトウェア所有者にパッチを開発する時間を与えるのが一般的です。

• サービス妨害（DoS）攻撃 – 悪意ある行動をとる者が、ウェブサイトをクラッシュさせることを目的として、リクエスト（TCP/UDPまたはHTTP/HTTPS）を大量に送信する攻撃です。DoS攻撃は可用性に影響を与えるため、主な成果はターゲットの評判へのダメージです。複数の攻撃元が同じネットワークやサービスを狙う分散型サービス妨害（DDoS）攻撃は、攻撃元のネットワークが大規模になる可能性があり、防御がより困難になります。DoS対策には、攻撃を効果的に識別し、防止するツールが必要です。詳しくは、「分散型サービス妨害（DDoS）とは？」をご覧ください。

• エンドツーエンドの暗号化（E2EE） – ユーザーからアプリケーションへのデータの受け渡しを完全に暗号化する手法です。E2EEにはSSL証明書と、場合によってはmTLSが必要です。

• 相互TLS（mTLS） – クライアントとホストの両方に（SSL/TLS証明書を介して）認証を要求する方法です。mTLSの使用は、クライアントとホスト間を通過するデータの機密性と完全性を保護します。mTLSは、同じクラスタ内の2つのサービス間においても、KubernetesのPodレベルで実施されます。SSL/TLSとmTLSの優れた入門書については、F5 Labsの「mTLSとは?」をご覧ください。

• シングルサインオン（SSO） – SSO技術（SAML、OAuth、OIDCなど）により、認証と認可の管理が容易になります。

  • 単純化された認証 – SSOは、異なるリソースや各機能のそれぞれに対し、ユーザーが個別のIDトークンを持つ必要性を排除します。

  • 標準化された承認 – SSOにより、役割、部署、役職に基づくユーザーのアクセス権設定が容易になり、各ユーザーに個別にアクセス権を設定する必要がなくなります。

• SSL (Secure Sockets Layer)/TLS (Transport Layer Security) – ネットワークに接続されたコンピュータ間で認証され、暗号化されたリンクを確立するためのプロトコル。SSL/TLS証明書は、ウェブサイトの身元を認証し、暗号化された接続を確立します。SSLプロトコルは1999年に廃止され、TLSプロトコルに置き換えられましたが、これらの関連技術を「SSL」または「SSL/TLS」と呼ぶのが一般的です。一貫性を保つために、この記事の残りの部分ではSSL/TLSを使用します。

• ウェブアプリケーションファイアウォール（WAF） – アプリケーションやAPIに対する高度な攻撃（OWASP Top 10などの高度な脅威を含む）を検知・遮断し、「安全な」トラフィックを通過させるリバースプロキシです。WAFは、機密データを盗んだり、システムを乗っ取ったりしてターゲットに危害を加えようとする攻撃から防御します。WAFとDoSの保護を同じツールに統合しているベンダーもあれば、WAFとDoSのツールを別々に提供しているベンダーもあります。

• ゼロトラスト – セキュリティの高い組織で頻繁に話題に上がるコンセプトですが、誰もが関係するセキュリティの概念です。そして、データの保管と転送のすべての段階でデータを保護することが求められます。これは、原則として組織はいかなるユーザーやデバイスも「信頼」しないことを決定し、全トラフィックを徹底的に検査することを前提していることを意味します。ゼロトラストアーキテクチャは、通常、認証、認可、およびmTLSの組み合わせを含み、組織がE2EEを実装している可能性が高いです。

ユースケース：CVEを迅速に解決し、サイバー攻撃を回避

ソリューション： タイムリーでプロアクティブなパッチ通知機能を持つツールを利用します。

Ponemon Instituteの調査によると、2019年、重要または優先度の高い脆弱性のパッチがリリースされてから、組織がその脆弱性を悪用した攻撃を確認するまでの期間が、平均43日であることがわかりました。F5 NGINXでは、この期間がその後の数年間で大幅に狭まる（「2021年のApple iOS 15の場合は０日(ゼロデイ攻撃)」となった）ことを確認しており、できるだけ早くパッチを適用することを推奨しています。しかし、トラフィックを制御するツールのパッチが、CVEが発表されてから数週間、あるいは数ヶ月間利用できない場合はどうでしょうか。

専任のエンジニアリングチームではなく、コミュニティのコントリビューターによって開発・保守されているツールは、CVEの発表から数週間または数カ月遅れる可能性があり、組織が43日間の期限内にパッチを適用できる可能性は低くなります。一つの例として、OpenRestyは、NGINX関連のセキュリティパッチを適用するのに4ヶ月を要しました。OpenRestyベースのIngress Controllerを使用している人は、少なくとも4ヶ月間は脆弱なままであり、オープンソースプロジェクトに依存するソフトウェアにパッチが適用されるまでに、さらに遅延が発生するのが実際のこととして発生するのです。

CVEパッチを最速で適用するためには、トラフィックを制御するツールを選択する際に2つの特性を確認する必要があります。

• 専任のエンジニアリングチーム – ツールの開発がコミュニティのボランティアではなくエンジニアリングチームによって管理されている場合、ツールがチームで適切で管理されていると認識することができ、できるだけ早くパッチをリリースするよう依頼できる可能性があります。
• 統合されたコードベース – (OpenRestyで議論したような)外部依存がなければ、パッチは直ちに適用するだけでよいのです。

CVEパッチの詳細については、「NGINX Plusによる迅速かつ容易なセキュリティ脆弱性の緩和」をご覧ください。

ユースケース：OWASP Top 10およびDoS攻撃の阻止

ソリューション： 柔軟でKubernetesに適したWAFとDoS防御の導入

Kubernetes上で動作するアプリケーションに適したWAFとDoS保護の選択は、（機能に加えて）2つの要素に左右されます。

• 柔軟性 – Kubernetes内部で最適なツールとして利用できるシナリオがあり、そしてインフラ環境を意識せずKubernetesの内部・外部に関わらず動作するツールが必要です。すべてのデプロイメントに同じツールを使用することで、ポリシーを再利用でき、SecOpsチームの学習曲線も低くなります。
• フットプリント – 最高のKubernetesツールはフットプリントが小さく、スループット、1秒あたりのリクエスト、およびレイテンシーへの影響を最小限に抑えながら、適切なリソース消費を可能にします。DevOpsチームは、セキュリティツールがアプリを遅くするという認識から抵抗することが多いため、フットプリントが小さく高性能なツールを選択することが、採用の確率を高めます。

WAFとDoS防御を統合したツールは一見効率的に見えますが、実際にはCPU使用率（フットプリントが大きくなるため）と柔軟性の両面で問題があると予想されます。WAFとDoS防御の両方を必要としない場合でも、一緒に展開することを余儀なくされるのです。結局のところ、この2つの問題はKubernetesデプロイメントに費やす全体のコストを押し上げ、他の重要なツールやサービスに対する予算の問題を引き起こす可能性があります。

組織に適したセキュリティツールを選択したら、次はそのツールをどこに配備するかを決定する番です。Kubernetesのアプリケーションを保護するためにアプリケーションサービスをデプロイできる場所は、通常4か所あります。

• フロントドア（F5 NGINX PlusやF5 BIG‑IPなどの外部ロードバランサー） – 複数のクラスタにグローバルポリシーを適用できるため、全体的な大枠の保護に適しています。
• エッジ（F5 NGINX Ingress ControllerなどのIngress Controller） – 単一クラスタに標準装備された「きめ細かい」保護を提供するのに理想的です。
• サービス （NGINX Plusなどの軽量ロードバランサー） – クラスタ内で少数のサービスがあり、独自のポリシーを共有する必要がある場合に必要なアプローチである可能性があります。
• Pod （アプリケーションの一部） – ポリシーがアプリケーションに固有である場合に使用される、非常に個別のアプローチです。

では、4つの選択肢のうち、どれが一番いいのでしょうか？それは、お客さまの機能要件と環境に依存します。

WAFを導入する場所

まずはじめに、定義した役割から利用することの多いWAFの導入方法について見ていきます。

• フロントドアとエッジ – 「多層防御」のセキュリティ戦略を好む組織では、外部ロードバランサーとIngress Controllerの両方にWAFを導入し、全体の保護と個別の保護のバランスを効率的に実現することをお勧めします。
• フロントドアまたはエッジ – 「多層防護」のセキュリティ戦略がない場合は、1ヶ所の利用も問題ありません。従来の NetOps チームがセキュリティを管理する場合、従来のプロキシ（外部ロードバランサー）上で管理する方が適切かもしれません。しかし、Kubernetesに慣れている（そして、セキュリティ設定がクラスタ設定の近くにあることを好む）DevSecOpsチームは、IngressレベルにWAFをデプロイすることを選択することができます。
• サービスまたはPod単位 – チームがサービスやアプリに特定の要件を持っている場合、アラカルト方式で追加のWAFをデプロイすることができます。しかし、このような場所には高いコストがかかることに注意してください。開発時間の増加やクラウド予算の増加に加えて、「どのWAFが意図せずにトラフィックをブロックしているのか」を判断するためのトラブルシューティングに関連する運用コストも増加する可能性があります。

DoS防御を導入する場所

DoS攻撃への対策は、フロントドアかIngress Controllerのどちらか1か所だけで済むので、より簡単です。フロントドアとエッジの両方にWAFを導入する場合、フロントドアのWAFの前にDoS防御を導入することをお勧めします。そうすれば、不要なトラフィックがWAFに到達する前に間引きされ、通信制御の処理に必要となるリソースをより効率的に利用できるようになります。

これらの各導入シナリオの詳細については、「Kubernetesでのアプリケーションサービスの導入、パート2」を参照してください。

ユースケース：アプリから認証・認可をオフロード

ソリューション： 入口での認証と認可の一元化

アプリケーションやサービスに組み込まれる非機能要件として、認証と認可がよく挙げられます。規模が小さい場合、アプリケーションの更新が頻繁ではない時における複雑さは管理可能であり許容できるでしょう。しかし、大規模になり、リリースの速度が速くなると、認証と認可をアプリに統合することが不可能になります。各アプリが適切に認証・認可を維持する場合には、アプリケーションのビジネス・ロジックの妨げになることがあり、さらに悪い場合、管理漏れが見落とされ情報漏えいにつながる可能性もあります。SSO技術を使用すればクレデンシャルを利用することで個別のユーザー名やパスワードの管理が不要となりセキュリティが向上しますが、開発者はアプリケーションのコードにSSOと連携するインタフェースを導入する必要があります。

より良い方法があります。：認証と認可をIngress Controllerにオフロードするのです。

Ingress Controllerは、すでにクラスタに入るすべてのトラフィックを精査し、適切なサービスにルーティングしているため、認証と認可を一元化するための効率的な選択肢となるのです。これにより、開発者はアプリケーション・コードでロジックを構築、維持、複製する負担がなくなり、代わりにネイティブなKubernetes APIを使用してIngress層でSSO技術を迅速に活用することができるようになります。

このトピックの詳細については、「Implementing OpenID Connect Authentication for Kubernetes with Okta and NGINX Ingress Controller」をご覧ください。

ユースケース：適切な権限管理によるセルフサービスの設定

ソリューション： ロールベースアクセスコントロール（RBAC）の導入

Kubernetesは、RBACを使用して、様々なタイプのユーザーに対し利用できるリソースの操作と制御が可能です。これは、管理者またはスーパーユーザーが、どのユーザーまたはユーザーグループがクラスタ内の任意のKubernetesオブジェクトまたは特定のネームスペースでどのような操作を許可するか決定できる、重要なセキュリティ対策となります。

Kubernetesの RBACはデフォルトで有効になっていますが、Kubernetesのトラフィックを制御するツールがRBACに対応し、組織のセキュリティニーズに合わせた利用について注意する必要があります。RBACを導入すると、ユーザーは、チケットを発行し作業が実施されるのを待つことなく、自分の仕事をするために必要な機能へのアクセス権を得ることができます。しかし、RBACが設定されていないと、ユーザーは必要のない、または権利のない権限を得ることができ、その権限が悪用されると脆弱性につながる可能性があります。

Ingress Controllerは、RBACを設定することで、多数の人やチームにサービスを提供できるツールの代表例です。Ingress Controllerはある単一のネームスペースであっても、細かなアクセス管理を実施することができ、RBACを利用してマルチテナントにおけるリソースの効果的な利用が可能となります。

例として、複数のチームがIngress Controllerを以下のように使用するとします。

• NetOpsチーム – アプリケーションの外部エントリポイント（ホスト名やTLS証明書など）を設定し、トラフィック制御ポリシーを各チームに委ねます。
• DevOpsチームA – TCP/UDPのロードバランシングとルーティングのポリシーを規定します。
• DevOpsチームB – 過剰なリクエストからサービスを保護するためのレート制限ポリシーを設定します。
• アイデンティティチーム – 認証と認可のコンポーネントを管理し、エンドツーエンドの暗号化戦略の一環としてmTLSポリシーを設定します。
• DevSecOpsチーム – WAFのポリシーを設定します。

NGINX Ingress ControllerでRBACを活用する方法については、「NGINX Ingress ControllerによるAdvanced Kubernetes Deployments」をご覧ください。このビデオの13:50から、RBACとリソース割り当てを活用してセキュリティ、セルフサービス、マルチテナンシーを実現する方法について、専門家が解説します。

ユースケース：エンドツーエンドの暗号化を実装

ソリューション： トラフィックを制御するツールの活用

機密情報や個人情報を扱う企業にとって、エンドツーエンドの暗号化（E2EE）はますます一般的な要件になりつつあります。金融データであれ、ソーシャルメディア上のメッセージであれ、消費者のプライバシーへの期待とGDPRやHIPAAなどの規制が相まって、この種の保護に対する需要が高まっています。E2EE を実現するための最初のステップは、SSL/TLS トラフィックを受け入れるようにバックエンドアプリ を設計するか、アプリから SSL/TLS 管理をオフロードするツール（セキュリティ機能、パフォーマンス、キー 管理などを分離するために望ましいオプション）を使用することです。その後、環境の複雑さに応じて、トラフィックを制御するツールを設定します。

最もよくあるシナリオ： Ingress Controllerを使用したE2EE

エンドポイントが1つだけのアプリ（シンプルなアプリや、Kubernetesに「リフト＆シフト」したモノリシックなアプリ）、またはサービス間通信がない場合、Ingress Controllerを使用してKubernetes内にE2EEを実装することが可能です。

ステップ1： Ingress Controllerは、サービス側またはmTLS証明書を使用した暗号化のためSSL/TLS接続のみを許可するようにし、理想的にはIngressとEgressの両方のトラフィックに対して許可するようにします。

ステップ2： アプリケーションに送信する前にIngress Controllerがトラフィックを復号化して再暗号化するために必要な設定を行います。これには、複数の方法があります。Ingress Controllerの要件に合わせて選択が可能です。

• Ingress ControllerがSSL/TLSパススルーをサポートしている場合、Service Name Indication（SNI）ヘッダーに基づき、SSL/TLS暗号化接続をルーティングすることができます。その際、接続の復号化や、SSL/TLS証明書や鍵へのアクセスは必要ありません。
• 別の方法として、SSL/TLSターミネーションを設定し、Ingress Controllerがトラフィックを終端し、バックエンドやアップストリームにプロキシすることができます – 平文またはKubernetesサービスにmTLSやサービスサイドSSL/TLSでトラフィックを再暗号化することによって実装可能です。

稀に必要となるシナリオ：Ingress ControllerとService Meshを利用したE2EE

クラスタ内でサービス間通信を行う場合、Ingress Controllerによる外部接続のトラフィックとService Meshによるサービス間トラフィックの2つのプレーンでE2EEを実装する必要があります。E2EEにおけるService Meshの役割は、特定のサービス同士の通信を許可し、安全な方法で通信できるようにすることです。E2EEのService Meshを設定する場合、サービス間のmTLS（証明書を必要とするように設定）とサービス間のトラフィックアクセス制御（どのサービスが通信を許可されるかを規定）の2つの要素によって、ゼロトラスト環境を有効にする必要があります。理想的には、Kubernetesクラスタ全体で真のE2EEセキュリティを実現するために、アプリケーション（Service Meshとingress egress Controllerによって管理される）間にもmTLSを実装することです。

やり取りされるデータの暗号化に関するさらなる詳細については、「NGINXService MeshのmTLSアーキテクチャ」をお読みください。

ユースケース：クライアントが信頼できる実装で強力な暗号を使用していることを確認

ソリューション： 連邦情報処理規格（FIPS）への準拠

ソフトウェア業界では通常、FIPSといえば、米国とカナダが共同で策定した「FIPS PUB 140-2 Security Requirements for Cryptographic Modules」という暗号技術に特化した出版物を指します。これは、米国とカナダの共同作業で、機密情報を保護するために両国の連邦機関が受け入れる暗号モジュールのテストと認証を標準化したものです。しかし、あなたは「私は北米の政府機関と仕事をするわけではないので、FIPSなんて関係ない」と言うでしょう。FIPSは事実上のグローバル暗号基準でもあるため、業界や地域に関係なく、FIPSに準拠することは賢明な行動と言えます。

FIPSへの準拠は難しいことではありませんが、オペレーティングシステムと関連するトラフィックを制御するツールの両方がFIPSモードで動作できることが必要です。FIPSへの準拠は、単にオペレーティングシステムをFIPSモードで動作させれば達成されるという誤解があります。オペレーティングシステムがFIPSモードであっても、Ingress Controllerと通信するクライアントが強力な暗号を使用していない可能性があります。FIPSモードで動作している場合、オペレーティングシステムとIngress Controllerは、一般的なSSL/TLS暗号のサブセットのみを使用することができます。

KubernetesのデプロイメントにFIPSを設定するのは、4つのステップからなります。

• ステップ1： FIPSモードに対応したオペレーティングシステムの設定
• ステップ2： オペレーティングシステムとOpenSSLがFIPSモードであることを確認
• ステップ3： Ingress Controllerのインストール
• ステップ4： FIPSステータスチェックを行い、FIPS 140-2への準拠を確認

以下の例では、NGINX Plusが使用するオペレーティングシステムとOpenSSL実装の両方でFIPSモードを有効にすると、NGINX Plusとの間のすべてのエンドユーザー・トラフィックは、検証済みのFIPS対応暗号エンジンを使用して復号化および暗号化されます。

FIPSについては、「NGINX PlusでFIPS準拠を実現する」で詳しく説明しています。

NGINXでKubernetesの安全性を高める

これらのセキュリティ手法の一部（またはすべて）を実装する準備が整った場合、使用するツールがユースケースをサポートするための適切な機能と性能を備えているか確認する必要があります。NGINXは、本番環境に対応したKubernetesトラフィックを制御するツールについて支援することができます。

• NGINX Ingress Controller – Kubernetes向けのNGINX PlusベースのIngress Controllerで、高度なトラフィック制御とシェーピング、監視と可視化、認証とSSOを処理し、APIゲートウェイとして機能します。

• F5 NGINX App Protect – F5の市場をリードするセキュリティ技術に基づいて構築され、NGINX Ingress ControllerとNGINX Plusに統合された最新のアプリとAPIのための包括的な保護機能です。導入シナリオの柔軟性とリソースの最適な活用のためにモジュラーアプローチを使用します。

  • NGINX App Protect WAF – OWASP Top 10とPCI DDSコンプライアンスから保護する強力かつ軽量なWAFです。

  • NGINX App Protect DoS – クラウドやアーキテクチャを問わず、一貫した適応性のある保護で行動的なDoSの検出とミティゲーションを実現します。

• F5 NGINX Service Mesh – 軽量ですぐに利用でき、開発者フレンドリーなService Meshで、エンタープライズサイドカーとしてNGINX Plusを搭載しています。

NGINX App Protect WAFとDoSを備えたNGINX Ingress Controllerの30日間無料トライアルをリクエストし、無料のNGINX Service Meshをダウンロードすることから始めましょう。