IBM Cloud Kubernetes Serviceのセキュリティー

APIサーバーへのアクセスはどのように許可されるのですか？

Kubernetes ではデフォルトで、どの要求も複数の段階を経て初めて API サーバーへのアクセスを許可されるようになっています。

認証

登録済みユーザーまたはサービス・アカウントの ID を検証します。

許可

認証済みのユーザーおよびサービス・アカウントの許可を制限し、必要なクラスター・コンポーネントにのみアクセスして操作できるようにします。

アドミッション制御

要求が Kubernetes API サーバーによって処理される前に、それらの要求を検証または変更します。 Kubernetes の多くの機能は、正しく機能するために、入場管理コントローラーを必要とします。

IBM Cloud Kubernetes Service は、私のAPIサーバーと etcd のデータストアを保護するために何を行いますか？

次の図は、認証、許可、アドミッション・コントロール、Kubernetes マスターとワーカー・ノードの間のセキュア接続に対応するクラスターのデフォルトのセキュリティー設定を示しています。

Kubernetes API サーバーと etcd のセキュリティーに関する機能を以下に示します。

完全に管理される専用 Kubernetes マスター

IBM Cloud Kubernetes Service に含まれるクラスターはすべて、IBM が所有する IBM Cloud アカウントで、IBM が管理する専用 Kubernetes マスターによって制御されます。 Kubernetes マスターは、他の IBM のお客様とは共用されない、以下の専用コンポーネントを使用してセットアップされます。

• etcd データ・ストア: Services、Deployments、Pods などのクラスターのすべての Kubernetes リソースを保管します。 Kubernetes ConfigMaps および Secrets は、ポッドで実行されるアプリで使用できるように、キー値ペアとして保管されるアプリ・データです。 etcd のデータは Kubernetes マスターのローカル・ディスクに保管され、IBM Cloud Object Storage にバックアップされます。 IBM Cloud Object Storage に転送中のデータも保存されたデータも暗号化されています。 クラスターの IBM Key Protect 暗号化を有効にすると、Kubernetes マスターのローカル・ディスク上の etcd データの暗号化を有効にできます。 etcd データがポッドに送信されるときには、データの保護と保全性を確保するために、データが TLS で暗号化されます。
• kube-apiserver: ワーカー・ノードから Kubernetes マスターへのすべてのクラスター管理要求のメインエントリー・ポイントとなります。 API サーバーは、ポッドやサービスなどのクラスター・リソースの状態を変更する要求を検証および処理してから、この状態を etcd データ・ストアに保管します。
• kube-scheduler: ポッドをどこにデプロイするかを決定します。このとき、キャパシティーとパフォーマンスのニーズ、ハードウェアとソフトウェアのポリシー制約、アンチアフィニティー仕様、およびワークロード要件が考慮されます。 要件に合致するワーカー・ノードが見つからなければ、ポッドはクラスターにデプロイされません。
• kube-controller-manager: レプリカ・セットをモニターし、対応するポッドを作成して、指定された状態を実現するためのコンポーネントです。
• Konnectivity: IBM Cloud Kubernetes Service- すべての Kubernetes マスターからワーカーノードへの通信に安全なネットワーク接続を提供する 専用コンポーネント。 KonnectivityサーバーはKonnectivityエージェントと連携し、マスターをワーカーノードに安全に接続します。 この接続は、ポッドやサービスに対する apiserver proxy 要求と、kubelet に対する kubectl top、exec、attach、logs の各要求をサポートしています。 ワーカー・ノードからマスターへの接続は、TLS 証明書で自動的に保護されます。

IBM サイト信頼性エンジニア (SRE) による継続的なモニタリング

Kubernetes マスター (すべてのマスター・コンポーネント、コンピュート・リソース、ネットワーキング・リソース、ストレージ・リソースを含む) は、IBM サイト信頼性エンジニア (SRE) によって継続的にモニターされます。 SRE は、最新のセキュリティー規格を適用し、悪意のあるアクティビティーを検出して対処し、IBM Cloud Kubernetes Service の信頼性と可用性を確保するための作業を行います。

CIS Kubernetes マスター・ベンチマーク

IBM Cloud Kubernetes Serviceを構成するために、IBM エンジニアは、Center of Internet Security (CIS) によって公開されている Kubernetes マスター・ベンチマークからの関連サイバー・セキュリティー・プラクティスに従います。 クラスター・マスターおよびすべてのワーカー・ノードは、ベンチマークを満たすイメージを使用してデプロイされます。

TLS によるセキュア通信

IBM Cloud Kubernetes Service を使用するユーザーは、資格情報を使用してサービスから認証を受ける必要があります。 認証されると、IBM Cloud Kubernetes Service が、Kubernetes API サーバーおよび etcd データ・ストアとの間の通信を暗号化する TLS 証明書を生成して、ワーカー・ノードと Kubernetes マスターの間のセキュアなエンドツーエンド通信を確立します。 これらの証明書は、クラスター間で共有されたり、Kubernetes マスター・コンポーネント間で共有されたりすることはありません。

ワーカー・ノードへの接続

Kubernetes は、https プロトコルを使用してマスターとワーカー・ノードの間の通信を保護しますが、デフォルトでは、ワーカー・ノードで認証は行われません。 この通信を確保するために、 IBM Cloud Kubernetes Service はクラスタが作成されると、 Kubernetes マスターとワーカーノードの間にKonnectivity接続を自動的に確立します。

微細化されたアクセス制御

アカウント管理者は、IBM Cloud Identity and Access Management (IAM) を使用して、IBM Cloud Kubernetes Service に対するアクセス権限を他のユーザーに付与できます。IBM Cloud IAM は IBM Cloud プラットフォーム、IBM Cloud Kubernetes Service、およびアカウント内のすべてのリソースのセキュア認証を提供します。 リソースにアクセスできるユーザーを制限し、ユーザーが正当な権限を悪用した場合に被る可能性がある損害を抑えるためには、適切なユーザー役割と権限をセットアップすることが重要です。 ユーザーが実行できる一連の操作を決定する、以下の事前定義ユーザー役割の中から選択することができます。

• プラットフォーム・アクセス役割: ユーザーが IBM Cloud Kubernetes Service で実行できるクラスターとワーカー・ノードの管理関連の操作を決定します。
• サービスへのアクセス権限 ：ユーザーに割り当てられている Kubernetes RBAC ロールと、 Kubernetes API サーバーに対してユーザーが実行できるアクションを決定します。 RBAC 役割を割り当てられたユーザーは、アプリ・デプロイメント、名前空間、構成マップなどの Kubernetes リソースを作成できます。 ユーザーに割り当てられる対応するRBACロールと関連する権限の詳細については 、「IAMサービスアクセスロール」 を参照してください。
• クラシックインフラストラクチャ ：クラシックインフラストラクチャのリソースへのアクセスを可能にします。 クラシック・インフラストラクチャー役割によって許可されるアクションの例としては、クラスター・ワーカー・ノード・マシンの詳細を表示したり、ネットワーク・リソースやストレージ・リソースを編集したりするアクションがあります。
• VPC インフラストラクチャー: VPC インフラストラクチャー・リソースへのアクセスを有効にします。 VPC インフラストラクチャー役割で許可されるアクションの例として、VPC の作成、サブネットの追加、浮動 IP アドレスの変更、VPC ブロック・ストレージ・インスタンスの作成などがあります。

クラスタのアクセス制御の詳細については[、「クラスタアクセスの割り当て」] を参照してください。

サービス・アカウント・トークンを介したポッド・アクセス

Kubernetes 1.21 以降を実行するクラスターの場合、Kubernetes API サーバーとの通信にポッドで使用されるサービス・アカウント・トークンは、時間制限付きで、自動的にリフレッシュされ、特定の対象ユーザー (ポッド) に有効範囲が設定されており、ポッドが削除されると無効化されます。 API サーバーとの通信を続行するには、リフレッシュされたトークン値を定期的に (毎分など) 読み取るようにアプリを設計する必要があります。 詳細については 、「バインドされたサービスアカウントトークン 」を参照してください。

アドミッション・コントローラー

アドミッション・コントローラーは、Kubernetes と IBM Cloud Kubernetes Service の特定の機能のために実装されています。 　アドミッション・コントローラーにより、クラスター内で特定の操作を許可するかどうかを決定するポリシーを、クラスター内にセットアップできます。 ポリシーでは、このアクションが、RBAC 役割を使用してユーザーに割り当てた一般許可の一部である場合でも、そのユーザーがアクションを実行できないときの条件を指定できます。 したがって、アドミッション・コントローラーは、Kubernetes API サーバーで API 要求が処理される前に適用されるセキュリティー層をクラスターに追加できます。

クラスターを作成すると、 IBM Cloud Kubernetes Service によって、デフォルトの Kubernetes アドミッション コントローラーが特定の順序で Kubernetes マスターに自動的にインストールされます。これはユーザーが変更することはできません。 kube-apiserver コンポーネント参照情報内のクラスター・バージョン別のデフォルトのアドミッション・コントローラーの順序を確認します。

クラスタに独自のアドミッションコントローラをインストールすることも、オプションのアドミッションコントローラを選択することもできます。 Portieris。 Portieris を使用すると、署名されていないイメージからのコンテナーのデプロイをブロックできます。

手動でインストールしたアドミッション・コントローラーが不要になった場合は、必ず、完全に削除してください。 アドミッション・コントローラーを完全に削除しておかないと、クラスターに対して実行する必要がある操作がすべてブロックされる可能性があります。

APIサーバーを保護するために他にできることはありますか？

クラスタマスタへのネットワーク接続は、いくつかの方法で制限できます

• プライベートクラウドサービスエンドポイントのみを有効にします：パブリック・サービス・エンドポイントは、クラシックなOpenshiftクラスタにのみ必要です。 すべてのVPCクラスタで無効にできます。 また、アカウントで VRFとService Endpointが有効になっ ている限り、古典的なKubernetesクラスタで無効にすることもできる。 これにより、パブリック・ネットワーク上の攻撃からクラスタ・マスターを保護します。
• コンテキスト・ベースの制限を有効にします：コンテキスト・ベースの制限（CBR）を使用して、クラスタのプライベートおよび/またはパブリック・サービス・エンドポイントへのネットワーク・アクセスを保護できます。 CBRルール内のサブネットから発信されるクラスタ・マスタへの許可された要求のみが許可されます。 詳しくは、コンテキスト・ベースの制限を使用する を参照のこと。

作業ノードの所有者は誰ですか？また、私はそれを保護する責任がありますか？

ワーカー・ノードの所有権は、作成するクラスターのタイプやインフラストラクチャー・プロバイダーの選択によって異なります。

• クラシッククラスタ ： IBM Cloud アカウントにワーカーノードがプロビジョニングされます。 ワーカー・ノードはお客様専用のものです。このためお客様は、ワーカー・ノードの OS および IBM Cloud Kubernetes Service コンポーネントに最新のセキュリティー更新とパッチが適用されるように、ワーカー・ノードに対するタイムリーな更新を要求する責任があります。
• VPCクラスター： IBM が所有する IBM Cloud アカウントにワーカーノードがプロビジョニングされ、悪意のあるアクティビティの監視とセキュリティアップデートの適用が可能になります。 VPC ダッシュボードを使用してワーカー・ノードにアクセスすることはできません。 ただし、IBM Cloud Kubernetes Service コンソール、CLI、または API を使用してワーカー・ノードを管理することはできます。 ワーカー・ノードを構成する仮想マシンはお客様専用のものです。このためお客様は、ワーカー・ノードの OS と IBM Cloud Kubernetes Service コンポーネントに最新のセキュリティー更新とパッチが適用されるように、タイムリーな更新を要求する責任があります。

詳しくは、IBM Cloud Kubernetes Service を使用する際の責任を参照してください。

ibmcloud ks worker update コマンドを定期的 (毎月など) に使用して、更新とセキュリティー・パッチをオペレーティング・システムにデプロイし、ワーカー・ノードを実行する Kubernetes バージョンを更新してください。 更新が有効になると、IBM Cloud コンソールまたは CLI でマスター・ノードとワーカー・ノードに関する情報を (例えば、ibmcloud ks clusters ls コマンドや ibmcloud ks workers ls --cluster <cluster_name> コマンドで) 表示したときに通知を受けます。 ワーカー・ノードの更新は、最新のセキュリティー・パッチを含む完全なワーカー・ノード・イメージとして IBM から提供されます。 更新を適用するには、ワーカー・ノードのイメージを再作成し、新しいイメージを再ロードする必要があります。 root ユーザーの鍵は、ワーカー・ノードが再ロードされると自動的にローテーションされます。

私のワーカーノードの設定はどのようになっているでしょうか？

以下の図は、悪意のある攻撃からワーカー・ノードを保護するために、すべてのワーカー・ノードにセットアップされているコンポーネントを示しています。

この図には、ワーカー・ノードとの間のセキュアなエンドツーエンド通信を保証するコンポーネントは含まれていません。 詳しくは、ネットワーク・セキュリティーを参照してください。

CIS-コンプライアントイメージ

すべての作業ノードには、Center of Internet Security（ CIS ）が公表しているベンチマークを実装したオペレーティングシステムが設定されています。 ユーザーもマシンの所有者も、このオペレーティング・システムを別のオペレーティング・システムに変更することはできません。 現在のOSバージョンを確認するには、 kubectl get nodes -o wide を実行してください。 IBM は、社内と社外のセキュリティー顧問チームと協力して、セキュリティー・コンプライアンスにおける潜在的な脆弱性と取り組んでいます。 オペレーティング・システムのセキュリティー更新およびパッチは、IBM Cloud Kubernetes Service で提供されるので、ユーザーがインストールを実行してワーカー・ノードをセキュアに保つ必要があります。

IBM Cloud Kubernetes Service Linux カーネルをワーカーノードに使用しています。 IBM Cloud Kubernetes Service ではすべての種類の Linux ディストリビューションに基づいてコンテナーを実行できます。 コンテナイメージがそのカーネル上で動作可能かどうかを、コンテナイメージのベンダーに確認してください。

サイト信頼性エンジニア (SRE) による継続的なモニタリング

ワーカー・ノードにインストールされたイメージは、脆弱性およびセキュリティー・コンプライアンスの問題を検出するために、IBM サイト信頼性エンジニア (SRE) によって継続的にモニターされます。 SRE は、脆弱性に対処するため、ワーカー・ノードのためのセキュリティー・パッチとフィックスパックを作成します。 ワーカーノードとそこで実行するアプリケーションの安全な環境を確保するため、これらのパッチが利用可能になったら必ず適用してください。

CIS Kubernetes ワーカー・ノードのベンチマーク

IBM Cloud Kubernetes Service を設定するには、 IBM のエンジニアは 、Center of Internet Security（ CIS ） が発行する Kubernetes ワーカーノードベンチマークから関連するサイバーセキュリティの実践に従います。 ワーカー・ノードが CIS Kubernetes ベンチマークの規格に照らして準拠しているかどうかを確認することができます。

コンピュート分離

ワーカー・ノードはあるクラスターに専用のものであり、他のクラスターのワークロードをホストしません。 標準的なクラシッククラスターを作成する際には、ワーカーノードを物理マシン（ベアメタル）として、または共有または専用物理ハードウェア上で稼働する仮想マシンとしてプロビジョニングするよう選択できます。 VPCクラスタ内の作業ノードは、共有インフラストラクチャ上の仮想マシンとしてのみプロビジョニングできます。

クラシックでベアメタルをデプロイするオプション

標準クラシック・クラスターを作成する場合、ワーカー・ノードを、仮想サーバー・インスタンスではなく、ベアメタル物理サーバーにプロビジョンすることを選択できます。 ベア・メタル・マシンでは、メモリーや CPU などのコンピュート・ホストの細かい制御が可能です。 このセットアップには、ホスト上で稼働する仮想マシンに物理リソースを割り振る仮想マシン・ハイパーバイザーは含まれません。 代わりに、ベア・メタル・マシンのすべてのリソースはワーカー専用であるため、リソースを共有したりパフォーマンスを低下させたりする「うるさい隣人」について心配する必要はありません。 ベア・メタル・サーバーはお客様専用であり、そのすべてのリソースをクラスターに使用できます。

暗号化されたディスク

デフォルトでは、すべてのワーカー・ノードに、ローカルの SSD、AES 256 ビット暗号化データ・パーティション 2 つがプロビジョンされます。 最初のパーティションには、ワーカー・ノードのブートに使用され、暗号化されていないカーネル・イメージが含まれています。 2 番目のパーティションは、コンテナー・ファイル・システムを保持し、LUKS 暗号キーを使用してアンロックされます。 クラスター内の各ワーカー・ノードには、独自の固有の LUKS 暗号キーがあり、IBM Cloud Kubernetes Service によって管理されます。 クラスターを作成する際やワーカー・ノードを既存のクラスターに追加する際に、この鍵は安全にプルされてから、暗号化ディスクのアンロック後に破棄されます。 暗号化はディスク入出力のパフォーマンスに影響します。 高性能のディスク入出力が必要なワークロードの場合、暗号化を有効/無効にした両方のクラスターをテストし、暗号化をオフにするかどうかの決定に役立ててください。

エキスパート AppArmor ポリシー

すべてのワーカーノードには、ブートストラップ時にワーカーノードにロードされるプロファイルによって適用されるセキュリティおよびアクセスポリシーが設定されています。 AppArmor ブートストラップ中にワーカーノードにロードされるプロファイルによって マシンのユーザーまたは所有者によって、AppArmor プロファイルを変更することはできません。

SSH の無効化

デフォルトでは、クラスターを悪意のある攻撃から保護するために、ワーカー・ノード上の SSH アクセスは無効になっています。 SSH アクセスが無効な場合、クラスターへのアクセスは Kubernetes API サーバーを経由するように強制されます。 Kubernetes API サーバーでは、すべての要求が、クラスター内で実行される前に、認証、許可、およびアドミッション制御モジュールで設定されたポリシーに照らして検査される必要があります。

標準クラスタを使用しており、ワーカーノードにさらに機能を追加したい場合は、 IBM Cloud Kubernetes Service が提供するアドオンの中から選択するか、 Kubernetes デーモンセットを使用して、すべてのワーカーノードで実行したいすべての機能を利用することができます。 実行しなければならない単発の作業については 、 Kubernetes のジョブを使用してください。

クラシック・クラスターのネットワーク・セグメンテーションとプライバシー

ネットワークを保護し、ネットワークへのアクセスを許可されたユーザーから被る可能性がある損害の範囲を制限するために、ワークロードを可能な限り分離し、公開するアプリとワーカー・ノードの数を制限する必要があります。

クラシッククラスタでは、デフォルトでどの程度のネットワークトラフィックが許可されていますか？

すべてのコンテナーが、事前定義の Calico ネットワーク・ポリシー設定で保護されます。この設定は、クラスターの作成時にすべてのワーカー・ノードに構成されます。 デフォルトでは、すべてのワーカー・ノードに対して、すべてのアウトバウンド・ネットワーク・トラフィックが許可されます。 インバウンド・ネットワーク・トラフィックは、以下の例外を除き、ブロックされます。

• NodePort: Kubernetes NodePort の範囲はデフォルトで開かれているので 、 NodePort サービス とともにアプリを公開することができます。 クラスター内の NodePort 上のインバウンド・ネットワーク・トラフィックをブロックするには、NLB サービスまたは NodePort サービスへのインバウンド・トラフィックの制御を参照してください。
• IBM モニタリング・ポート: デフォルトでは、IBM はクラスター上でいくつかのポートを開きます。これは、IBM がネットワーク・トラフィックをモニターできるようにするため、また、IBM が Kubernetes マスターのセキュリティー更新を自動的にインストールするためのものです。

Kubernetes マスターからワーカーノードの kubelet へのアクセスは、Konnectivity トンネルによって保護されています。 詳しくは、IBM Cloud Kubernetes Service アーキテクチャーを参照してください。

ネットワークセグメントとは何ですか？また、クラシッククラスタに設定するにはどうすればよいですか？

ネットワーク・セグメンテーションとは、1 つのネットワークを複数のサブネットワークに分割する方式を表すものです。 組織内の特定のグループからアクセスできるように、アプリと関連データをグループ化できます。 1 つのサブネットワーク内で実行されるアプリは、別のサブネットワーク内のアプリを表示することも、別のサブネットワーク内のアプリにアクセスすることもできません。 ネットワーク・セグメンテーションは、内部関係者やサード・パーティー製ソフトウェアに提供されているアクセスも制限するので、さまざまな悪意のあるアクティビティーを制限できます。

IBM Cloud Kubernetes Service には、ワーカー・ノードのために高品質のネットワーク・パフォーマンスとネットワークの分離を実現する IBM Cloud VLAN が用意されています。 VLAN では、ワーカー・ノードとポッドをまとめたグループが同じ物理ワイヤーに接続されているかのように構成されます。 VLAN は各 IBM Cloud アカウントに専用のものであり、複数の IBM カスタマーの間で共有されることはありません。 クラシック・クラスターで、1 つのクラスターに複数の VLAN がある場合、同じ VLAN 上に複数のサブネットがある場合、または複数ゾーン・クラシック・クラスターである場合は、IBM Cloud インフラストラクチャー・アカウントの仮想ルーター機能 (VRF) を有効にして、ワーカー・ノードがプライベート・ネットワーク上で相互に通信できるようにする必要があります。 VRF を有効にするには、VRF の有効化を参照してください。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にします。 この操作を行うには 、「ネットワーク > ネットワークVLANスパニングインフラストラクチャの管理」権限が必要です。または、アカウント所有者に権限の付与を依頼することもできます。 VLANスパニングがすでに有効になっているかどうかを確認するには、 ibmcloud ks vlan spanning get --region <region>指示。

アカウントで VRF または VLAN スパンニングを有効にすると、クラスターのネットワーク・セグメンテーションが失われます。

アカウントで VRF または VLAN スパンニングを有効にした状況でネットワーク・セグメンテーションを実現する方法を、以下の表で確認してください。

クラシッククラスタの外部攻撃対象領域を減らすために、他に何ができるでしょうか？

公開するアプリやワーカー・ノードの数が多いほど、外部からの悪意のある攻撃を防止するために必要なステップの数も多くなります。 以下の表で、アプリとワーカー・ノードをプライベートにするために取れる方法を確認してください。

クラスタをオンプレミスのデータセンターに接続したい場合はどうすればよいですか？

ワーカー・ノードとアプリをオンプレミス・データ・センターに接続するには、strongSwan サービス、仮想ルーター・アプライアンス、または Fortigate Security Appliance を使用して VPN IPsec エンドポイントを構成します。

VPC クラスターのネットワーク・セグメンテーションとプライバシー

ネットワークを保護し、ネットワークへのアクセスを許可されたユーザーから被る可能性がある損害の範囲を制限するために、ワークロードを可能な限り分離し、公開するアプリとワーカー・ノードの数を制限する必要があります。

デフォルトで、私のVPCクラスタに許可されているネットワークトラフィックはどのくらいですか？

デフォルトでは、ワーカー・ノードはプライベート・ネットワーク上の VPC サブネットにのみ接続されるため、ワーカー・ノードにパブリック・ネットワーク・インターフェースは存在しません。 ワーカー・ノードへのすべてのパブリック受信がブロックされます。 ワーカー・ノードからのパブリック送信は、ワーカーがパブリック・ゲートウェイを持つ VPC サブネットに接続されている場合にのみ許可されます。

ワーカー・ノードがクラスター外部のパブリック・エンドポイントにアクセスする必要がある場合は、ワーカー・ノードをデプロイした VPC サブネットにパブリック・ゲートウェイを接続します。 例えば、VPC クラスターは、プライベート・クラウド・サービス・エンドポイントをサポートする他の IBM Cloud サービス (IBM Cloud Container Registry など) に自動的に接続できます。 しかし、パブリック・クラウド・サービス・エンドポイントのみをサポートする IBM Cloud サービスにアクセスする必要がある場合は、ポッドがパブリック・ネットワークを介して要求を送信できるように、サブネットにパブリック・ゲートウェイを接続できます。 パブリック・ゲートウェイを接続したサブネットのワーカー・ノードでは、すべての送信が許可されるようになります。ただし、受信は引き続きすべてブロックされます。

インターネットからのトラフィック要求を受信する必要があるアプリをクラスターにデプロイする場合は、VPC ロード・バランサーを作成してアプリを公開します。 アプリへの受信ネットワーク・トラフィックを許可するには、VPC ロード・バランサーに、受け取りたい受信ネットワーク・トラフィックを構成する必要があります。

セキュリティグループは、VPCインスタンスとVPC ALBにデフォルトで適用されます。 詳しくは、VPC セキュリティー・グループによるトラフィックの制御を参照してください。

ネットワークセグメントとは何ですか？また、VPCクラスタにそれを設定するにはどうすればよいですか？

ネットワーク・セグメンテーションとは、1 つのネットワークを複数のサブネットワークに分割する方式を表すものです。 組織内の特定のグループからアクセスできるように、アプリと関連データをグループ化できます。 1 つのサブネットワーク内で実行されるアプリは、別のサブネットワーク内のアプリを表示することも、別のサブネットワーク内のアプリにアクセスすることもできません。 ネットワーク・セグメンテーションは、内部関係者やサード・パーティー製ソフトウェアに提供されているアクセスも制限するので、さまざまな悪意のあるアクティビティーを制限できます。

IBM Cloud Kubernetes Service には、ワーカー・ノードのために高品質のネットワーク・パフォーマンスとネットワークの分離を実現する IBM Cloud VPC サブネットが用意されています。 VPC サブネットは、指定したプライベート IP アドレス範囲 (CIDR ブロック) から構成され、一連のワーカー・ノードとポッドを、物理的に同じ線に接続されているかのように構成します。 VPC サブネットは各 IBM Cloud アカウントに専用のものであり、複数の IBM カスタマーの間で共有されることはありません。

VPC サブネットは、クラスター内のワーカー・ノード間の接続チャネルとして機能します。 同じ VPC であれば、どのプライベート・サブネットであろうとプライベート・サブネットに接続したシステムはワーカーと通信できます。 例えば、1 つの VPC 内のすべてのサブネットは、標準装備の VPC ルーターによるレイヤー 3 のプライベートなルーティングを介して通信できます。 クラスターが通信を行う必要がない場合は、別個の VPC にクラスターを作成することで最適なネットワーク・セグメンテーションを実現できます。 複数のクラスターが相互に通信する必要がある場合は、それらのクラスターを同じ VPC 内に作成することができます。 1 つの VPC 内のサブネットはその VPC 内の複数のクラスターで共有できますが、VPC 内のクラスターごとに別のサブネットを使用するほうが、ネットワーク・セグメンテーションは細かくなります。

アカウントの VPC のサブネット間でプライベート・ネットワーク・セグメンテーションをさらに細かくするには、VPC アクセス制御リスト (ACL) を使用してカスタム・ネットワーク・ポリシーをセットアップします。 VPC を作成すると、VPC のデフォルト ACL が allow-all-network-acl-<VPC_ID> のフォーマットで作成されます。 VPC に作成するサブネットは、デフォルトでこの ACL にアタッチされます。 この ACL には、特定のサブネット上のワーカー・ノードと、同じ VPC 内の各サブネット上のシステムの間のトラフィックをすべて許可するインバウンド・ルールとアウトバウンド・ルールが入っています。 VPC サブネット上のワーカー・ノードに許可するプライベート・ネットワーク・トラフィックを指定するには、VPC 内のサブネットごとにカスタム ACL を作成します。 例えば、クラスターのインバウンド/アウトバウンドのプライベート・ネットワーク・トラフィックの大部分をブロックする一方で、クラスターが機能するために必要な通信を許可するように 一連の ACL ルールを作成することができます。

VPCクラスタに対する外部からの攻撃対象領域を減らすために、他に何ができるでしょうか？

公開するアプリやワーカー・ノードの数が多いほど、外部からの悪意のある攻撃を防止するために必要なステップの数も多くなります。 以下の表で、アプリとワーカー・ノードをプライベートにするために取れる方法を確認してください。

ワーカー・ノードを接続したいネットワークに応じて、VPN ソリューションを選択できます。

LoadBalancer サービスと Ingress サービスを使用したアプリの安全な公開

ネットワーク・ロード・バランサー (NLB) および Ingress アプリケーション・ロード・バランサー (ALB) のネットワーク・サービスを使用して、アプリを公共のインターネットまたは外部プライベート・ネットワークに接続できます。 以下に記載している NLB および ALB のオプションの設定を使用して、バックエンド・アプリのセキュリティー要件を満たしたり、クラスター内を移動するトラフィックを暗号化したりできます。

セキュリティグループを使用してクラスタのネットワークトラフィックを管理することはできますか？

クラシック・クラスター: IBM Cloud セキュリティー・グループは、単一仮想サーバーのネットワーク・インターフェースに適用され、ハイパーバイザー・レベルでトラフィックをフィルタリングします。 ワーカー・ノードごとにトラフィックを管理する場合は、セキュリティー・グループを使用できます。 セキュリティー・グループを作成する場合は、NLB の IP アドレスを管理するために IBM Cloud Kubernetes Service で使用される VRRP プロトコルを許可する必要があります。 クラスタのトラフィックをすべてのワーカーノードで統一的に管理するには、 Calico および Kubernetes ポリシー を使用します。

VPC クラスター: VPC セキュリティー・グループは、ハイパーバイザー・レベルでトラフィックをフィルタリングするために単一仮想サーバーのネットワーク・インターフェースに適用されます。 クラスターのデフォルトのセキュリティー・グループにインバウンドおよびアウトバウンドのルールを追加して、VPC クラスターのインバウンドおよびアウトバウンドのトラフィックを管理できます。 デフォルト設定を含むセキュリティー・グループについて詳しくは、 VPC セキュリティー・グループによるトラフィックの制御 を参照してください。

VPC クラスターのワーカー・ノードはサービス・アカウントで存在し、VPC インフラストラクチャー・ダッシュボードにはリストされないため、セキュリティー・グループを作成してワーカー・ノード・インスタンスに適用することはできません。 自動的に作成された既存のセキュリティー・グループを変更することだけが可能です。

クラスタ内のソースIPをどのようにして保護できますか？

バージョン 2.0 の NLB では、クライアント要求のソース IP アドレスはデフォルトで保持されます。 ただし、バージョン 1.0 の NLB およびすべての Ingress ALB では、クライアント要求のソース IP アドレスが保持されません。 アプリへのクライアント要求がクラスターに送信されると、その要求は、NLB 1.0 または ALB のポッドに転送されます。 ロード・バランサー・サービス・ポッドと同じワーカー・ノードにアプリ・ポッドが存在しない場合、NLB または ALB は異なるワーカー・ノード上のアプリ・ポッドに要求を転送します。 パッケージのソース IP アドレスは、アプリ・ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。

クライアントの IP を保持すると、例えば、アプリ・サーバーがセキュリティーやアクセス制御ポリシーを適用する必要がある場合などに役に立ちます。 クライアント要求の元のソース IP アドレスを保持するには、バージョン 1.0 の NLB または Ingress ALB のソース IP 保持を有効化します。

LoadBalancer とIngressサービスでTLS終端を行うにはどうすればよいですか？

Ingress サービスは、トラフィック・フロー内の次の 2 つのポイントで TLS 終端処理を実行します。

• 到着時にパッケージを復号化：デフォルトでは、Ingress ALBは HTTP のネットワークトラフィックをクラスタ内のアプリケーションにロードバランスします。 着信 HTTPS 接続のロード・バランシングも行う場合は ALB でその機能を構成できます。つまり、ネットワーク・トラフィックを復号し、復号した要求をクラスター内で公開されているアプリに転送するように構成します。 IBM 提供の Ingress サブドメインを使用する場合は、IBM 提供の TLS 証明書を使用できます。 カスタム・ドメインを使用する場合は、独自の TLS 証明書を使用して TLS 終端を管理できます。
• パッケージをアップストリーム・アプリに転送する前に再暗号化する: ALB は、トラフィックをアプリに転送する前に HTTPS 要求を復号します。 HTTPS を必要とするアプリがあり、それらのアップストリームのアプリに転送する前にトラフィックを暗号化する必要がある場合は、ssl-services アノテーションを使用できます。 アップストリーム・アプリが TLS を処理できる場合は、片方向認証または双方向認証の TLS シークレットに含まれる証明書をオプションで提供できます。

サービス間の通信を保護するには 、Istioの相互TLS認証を使用できます。 Istio は Kubernetes などのクラウド・オーケストレーション・プラットフォームでマイクロサービス・ネットワーク (サービス・メッシュともいう) の接続、保護、管理、モニターを行うための方法を開発者に提供するオープン・ソース・サービスです。

シングルテナントまたはマルチテナントのクラスタをセットアップすべきでしょうか？

単一テナント・クラスターでは、クラスターでワークロードを実行する必要があるユーザー・グループごとに、クラスターを 1 つ作成します。 通常、そのチームが、クラスターを管理し、正しく構成して保護します。 マルチテナント・クラスターは、複数の名前空間を使用してテナントとそのワークロードを分離します。

シングル・テナント・クラスターとマルチテナント・クラスターのどちらにするかは、クラスター内でワークロードを実行するチーム数、各チームのサービス要件、サービスのサイズ、およびワークロードに必要な分離レベルに基づいて決定します。

複雑なサービスを実行するチームが多く、チームごとにクラスターのライフサイクルを管理する必要がある場合には、シングル・テナント・クラスターが適しているでしょう。 クラスターの更新時期や、クラスターにデプロイできるリソースを自由に決められます。 他のテナントをセキュリティー侵害の危険にさらさずに特権ポッドを使用したい場合も、シングル・テナント・クラスターを構成できます。 クラスターを管理するには、デプロイメントに応じたクラスターの容量とセキュリティーを確保するために、Kubernetes とインフラストラクチャーに関する詳細な知識が必要であることに注意してください。

マルチテナント・クラスターは、Kubernetes 名前空間を使用してテナントを分離し、通常は、いずれのテナントにも属さない別個のチームによって管理されます。 クラスターで小さなワークロードを実行する必要があるチームが複数存在するが、複数のゾーンをまたぐ高可用性のシングル・テナント・クラスターを作成することでは必要な費用便益が得られないという場合は、マルチテナント・クラスターが適しているでしょう。 マルチテナント・クラスターは、通常、少ない人数でクラスターを操作および管理するので、必要な分離レベルが得られず、また、以下の領域の複雑さが増す可能性があります。

• アクセス: 複数の名前空間をセットアップする場合は、名前空間ごとに適切な RBAC ポリシーを構成して、確実にリソースを分離する必要があります。 RBAC ポリシーは複雑であるため、Kubernetes に関する詳細な知識が必要です。
• 特権ポッド: マルチテナント・クラスター内の 1 つのテナントで特権ポッドを実行する必要がある場合、このポッドはクラスター内の他の名前空間にアクセスすることも、共有コンピュート・ホストに損害を与えることも可能です。 特権ポッドの制御は複雑な作業であり、手間と深い技術的専門知識が必要です。 クラスター内のテナントでデプロイできるリソースを制御するには、ポッド・セキュリティー・ポリシー (PSP) を使用します。
• ネットワーク・ポリシー: ワーカー・ノードが同じプライベート・ネットワークに接続されているため、ポッドが他の名前空間内のポッドにアクセスできないように、厳しいネットワーク・ポリシーを設定する必要があります。
• リソースの制限 ：すべてのチームがクラスタ内でサービスを展開し、アプリケーションを実行するために必要なリソースを確保できるように、すべてのネームスペースに対して リソースの割り当て上限を設定する必要があります。 リソースの割り当ては、展開の制約を決定します。例えば、 Kubernetes リソースの展開可能数や、それらのリソースが消費できるCPUとメモリの量などがこれに該当します。 割り当て量を設定すると、ユーザーは、そのデプロイメントにリソース要求と制限を含める必要があります。
• 共有クラスター・リソース: 1 つのクラスターで複数のテナントを実行する場合は、Ingress アプリケーション・ロード・バランサー (ALB) や使用可能なポータブル IP アドレスなどの一部のクラスター・リソースが、複数のテナント間で共有されます。 小規模なサービスは、クラスター内の大規模なサービスと競合する場合、共有リソースを使用できないことがあります。
• 更新: 同時に実行できる Kubernetes API のバージョンは 1 つだけです。 1 つのクラスター内で実行されるすべてのアプリは、そのアプリを所有しているチームにかかわらず、現行の Kubernetes API バージョンに準拠していなければなりません。 クラスターを更新する場合は、すべてのチームが新しい Kubernetes API バージョンに切り替える準備ができていることと、それに対応するようにアプリが更新されていることを確認する必要があります。 つまり、個々のチームが、実行する Kubernetes API のバージョンを制御することはほぼできないということです。
• クラスター・セットアップの変更: クラスターのセットアップを変更したり、ワークロードを新しいワーカー・ノードにスケジュール変更したりする場合は、その変更をテナント間にロールアウトする必要があります。 このロールアウトには、単一テナント・クラスターの場合よりも多くの調整とテストが必要です。
• コミュニケーション・プロセス: 複数のテナントを管理する場合は、クラスターに問題があるときやサービス用に追加のリソースが必要になったときに問い合わせる場所がテナントにわかるように、コミュニケーション・プロセスをセットアップすることを検討してください。 このコミュニケーション・プロセスには、クラスターのセットアップのあらゆる変更や更新予定をテナントに知らせることも含まれます。

単一テナント・クラスターとマルチテナント・クラスターのコストはだいたい同じですが、単一テナント・クラスターではマルチテナント・クラスターの名前空間よりも高い分離のレベルが提供されます。 高いワークロード分離が必要な場合は、シングル・テナント・クラスターを使用してください。

Kubernetes ネットワーク・ポリシーは、内部ネットワーク・トラフィックからポッドを保護します。 例えば、多くのポッドまたはすべてのポッドで特定ポッド/サービスへのアクセスが不要である場合に、デフォルトでポッドがそのポッド/サービスにアクセスできないようにしたいのであれば、Kubernetes ネットワーク・ポリシーを作成して、そのポッド/サービスへの ingress トラフィックをブロックできます。 また Kubernetes ネットワーク・ポリシーは、別々の名前空間内のポッドとサービスの通信方法を制御して、名前空間の間のワークロードの分離を実施するのに役立ちます。

ポッドの権限を制御するにはどうすればよいですか？

デフォルトでは、すべてのクラスタ で Kubernetes ポッドセキュリティポリシーアドミッションコントローラが有効になっています。このポリシーを使用して、ポッドがネームスペースにデプロイされるために満たさなければならない要件を定義することができます。 ポッド・セキュリティー・ポリシーを使用すると、特権コンテナー、ルート名前空間、ホスト・ネットワーキングとポート、ボリューム・タイプ、ホスト・ファイル・システム、Linux の権限 (読み取り専用やグループ ID など) の使用方法を制御できます。 詳しくは、ポッド・セキュリティー・ポリシーの構成 を参照してください。

コンテナを保護するために他にできることはありますか？

特権コンテナの数を制限する。 コンテナーは、他のプロセスから分離された独立した Linux プロセスとしてコンピュート・ホスト上で実行されます。 他の Linux プロセス、ホスト・ファイル・システム、ホスト・デバイスを保護するために、コンテナーの中で root 権限を持つユーザーでも、コンテナーの外では権限が制限されます。 一部のアプリは、ホスト・ファイル・システムへのアクセス権限や高い権限がないと、正しく機能しません。 コンテナーを特権モードで実行すると、コンピュート・ホストで実行されるプロセスと同じアクセス権限を、そのコンテナーに許可できます。

特権コンテナーが乗っ取られると、クラスターおよび基礎コンピュート・ホストに甚大な損害がもたらされる可能性があることに注意してください。 特権モードで実行するコンテナーの数を制限し、高い権限がなくても実行できるようにアプリの構成を変更することを検討してください。

特権コンテナーをクラスター内で実行できないようにするには、カスタムのポッド・セキュリティー・ポリシーをセットアップすることを検討してください。

OS セキュリティー設定をポッドに適用する

securityContext セクションをポッドに追加することで、コンテナ内で実行できるユーザーIDとグループID、またはボリュームマウントパスを所有するユーザーIDとグループIDを制御することができます。 特定のユーザー ID を設定すると、最小特権モデルが円滑化されます。 セキュリティー・コンテキストによってユーザーが指定されない場合、Kubernetes は、コンテナー・イメージで指定されているユーザーを自動的に使用します。

securityContext を使用して runAsUser ユーザー ID または fsGroup グループ ID を設定する場合は、永続ストレージを作成するときにブロック・ストレージを使用することを検討してください。 NFS ストレージは fsGroup をサポートしません。runAsUser は、ポッド・レベルではなくコンテナー・レベルで設定する必要があります。

コンテナー用の CPU とメモリーの制限を設定する

どのコンテナーも、正常に起動して実行し続けるためには、特定の量の CPU とメモリーが必要です。 Kubernetes リソース要求とリソース制限をコンテナまたはポッドに対して定義することで、それらが消費できるCPUとメモリの量を制限することができます。 CPU とメモリーの制限を設定しない場合、コンテナーがビジーになると、使用可能なすべてのリソースが使用されます。 このようなリソースの大量消費は、正常に始動/稼働するだけの十分なリソースを持たないワーカー・ノード上の他のコンテナーに影響を与える可能性があり、ワーカー・ノードをサービス妨害攻撃のリスクにさらします。

ポリシー駆動の認証を実施する

サービスと API へのアクセスを制御するために、Ingress アノテーションをデプロイメントに追加できます。 App ID と宣言セキュリティーを使用して、ユーザー認証とトークンの検証を確認できます。