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

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

認証

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

許可

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

アドミッション制御

要求が Red Hat OpenShift API サーバーによって処理される前に、検証または変更します。 多くの Kubernetes 機能が正しく機能するためには、アドミッションコントローラーが必要です。

APIサーバーと etcd データストアを保護するために、 Red Hat OpenShift on IBM Cloud は何をしますか？

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

Red Hat OpenShift API サーバーおよび etcd の以下のセキュリティー機能を確認してください。

完全に管理される専用 Red Hat OpenShift マスター

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

• etcd データ・ストア: Services、Deployments、Pods などのクラスターのすべての Kubernetes リソースを保管します。 Kubernetes ConfigMaps および Secrets は、ポッドで実行されるアプリで使用できるように、キー値ペアとして保管されるアプリ・データです。 etcd のデータは Red Hat OpenShift マスターのローカル・ディスクに保管され、IBM Cloud Object Storage にバックアップされます。 IBM Cloud Object Storage に転送中のデータも保存されたデータも暗号化されています。 クラスターの IBM Key Protect 暗号化の有効によって、Red Hat OpenShift マスターのローカル・ディスク上の etcd データの暗号化を有効にすることができます。 etcd データがポッドに送信されるときには、データの保護と保全性を確保するために、データが TLS で暗号化されます。
• openshift-api: ワーカー・ノードから Red Hat OpenShift マスターへのすべてのクラスター管理要求のメインエントリー・ポイントとなります。 API サーバーは、ポッドやサービスなどのクラスター・リソースの状態を変更する要求を検証および処理してから、この状態を etcd データ・ストアに保管します。
• openshift-controller: 新しく作成されたポッドを監視し、容量、パフォーマンスのニーズ、ポリシー制約、アンチアフィニティー仕様、およびワークロード要件に基づいて、それらのポッドをデプロイする場所を決定します。 要件に合致するワーカー・ノードが見つからなければ、ポッドはクラスターにデプロイされません。 コントローラーでは、レプリカ・セットなどのクラスター・リソースの状態も監視されます。 リソースの状態が変化する (例えば、レプリカ・セット内のポッドがダウンする) と、コントローラー・マネージャーは、必要な状態を実現するための修正アクションを開始します。
• cloud-controller-manager: クラウド・コントローラー・マネージャーは、IBM Cloud ロード・バランサーなどのクラウド・プロバイダー固有コンポーネントを管理します。
• Konnectivity: Red Hat OpenShift マスターノードからワーカーノードへのすべての通信に安全なネットワーク接続を提供する、 Red Hat OpenShift on IBM Cloud 特有のコンポーネント。 KonnectivityサーバーはKonnectivityエージェントと連携し、マスターとワーカーノードを安全に接続します。 この接続は、ポッドやサービスに対する apiserver proxy 要求と、kubelet に対する oc exec、attach、logs 要求をサポートしています。 ワーカー・ノードからマスターへの接続は、TLS 証明書で自動的に保護されます。

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

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

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

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

TLS によるセキュア通信

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

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

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

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

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

• プラットフォーム役割: ユーザーが Red Hat OpenShift on IBM Cloud で実行できるクラスターとワーカー・ノードの管理関連の操作を決定します。 また、プラットフォーム・アクセスの役割を介して、ユーザーには RBAC 役割の basic-users および self-provisioners が割り当てられます。 これらの RBAC ロールを使用して、クラスタ内に Red Hat OpenShift プロジェクトを作成し、そこにアプリや Kubernetes リソースをデプロイできます。 プロジェクトの作成者は、プロジェクトの admin RBAC 役割を自動的に割り当てられるので、プロジェクトにデプロイして実行するものを完全に制御できます。 ただし、これらの RBAC 役割では、他の Red Hat OpenShift プロジェクトへのアクセス権限を付与するものではありません。 他の Red Hat OpenShift プロジェクトを表示してアクセスするには、IAM で適切なサービス・アクセス役割を割り当てられる必要があります。
• サービス・アクセス・ロール： ユーザーに割り当てられる Kubernetes RBAC ロールと、ユーザーが Red Hat OpenShift API サーバーに対して実行できるアクションを決定します。 プラットフォーム・アクセス役割が割り当てられた basic-users および self-provisioners RBAC 役割では、独自の Red Hat OpenShift プロジェクトを作成および管理できますが、サービス・アクセス役割が割り当てられるまで、他の Red Hat OpenShift プロジェクトを表示、アクセス、または操作することはできません。 ユーザーに割り当てられる対応するRBACロールと関連する権限の詳細については、 IAMサービス・アクセス・ロールを 参照してください。
• クラシック・インフラストラクチャ： 従来のインフラリソースへのアクセスを可能にします。 クラシック・インフラストラクチャー役割によって許可されるアクションの例としては、クラスター・ワーカー・ノード・マシンの詳細を表示したり、ネットワーク・リソースやストレージ・リソースを編集したりするアクションがあります。
• VPC インフラストラクチャー: VPC インフラストラクチャー・リソースへのアクセスを有効にします。 VPC インフラストラクチャー役割で許可されるアクションの例として、VPC の作成、サブネットの追加、浮動 IP アドレスの変更、VPC ブロック・ストレージ・インスタンスの作成などがあります。

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

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

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

クラスタを作成すると、 Red Hat OpenShift on IBM Cloud は自動的にデフォルトの Kubernetes アドミッションコントローラを Red Hat OpenShift マスターに特定の順序でインストールします。 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 コンポーネントに最新のセキュリティー更新とパッチが適用されるように、タイムリーな更新を要求する責任があります。

詳しくは、Red Hat OpenShift on IBM Cloud を使用するうえでの責任を参照してください。

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

ワーカーノードのセットアップはどうなっていますか？

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

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

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

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

Red Hat OpenShift on IBM Cloud Linux カーネルをワーカーノードに使用しています。 Red Hat OpenShift on IBM Cloud ではすべての種類の Linux ディストリビューションに基づいてコンテナーを実行できます。 コンテナ・イメージのベンダーに問い合わせて、コンテナ・イメージがカーネル上で実行できることを確認する。

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

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

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

Red Hat OpenShift on IBM Cloud を設定するために、 IBM のエンジニアは、 Center of Internet Security(CIS) が公開している Kubernetes ワーカー・ノード・ベンチマークから、関連するサイバーセキュリティのプラクティスに従う。 CIS Kubernetes ベンチマークおよび Red Hat OpenShift ベンチマークの規格を基準にして、ワーカー・ノードの準拠性を評価できます。

コンピュート分離

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

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

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

暗号化されたディスク

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

SELinux

すべてのワーカーノードは、ブートストラップ中にワーカーノードにロードされる Security-Enhanced Linux(SELinux) プロファイルによって強制されるセキュリティとアクセスポリシーでセットアップされます。 SELinux プロファイルをマシンのユーザーまたは所有者が変更することはできません。

SSH の無効化

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

標準的なクラスタを使用していて、ワーカーノードにより多くの機能をインストールしたい場合、 Red Hat OpenShift on IBM Cloud が提供するアドオンの中から選択するか、すべてのワーカーノードで実行したいすべてのものに対して Kubernetes デーモンセットを使用することができます。 一度だけ実行する必要があるアクションには、 Kubernetes ジョブを使用します。

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

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

Classicクラスタでは、デフォルトでどのようなネットワーク・トラフィックが許可されますか？

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

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

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

ネットワーク・セグメンテーションとは何ですか?

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

Red Hat OpenShift on IBM Cloud には、ワーカー・ノードのために高品質のネットワーク・パフォーマンスとネットワークの分離を実現する 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 oc vlan spanning get --region <region> コマンドを 使用します。

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

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

クラシック・クラスタに対する外部からの攻撃の可能性を減らすために、他にできることはありますか？

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

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

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

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

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

デフォルトでVPCクラスタに許可されるネットワーク・トラフィックは何ですか？

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

VPC のプライベート・ネットワークに接続することなく、Red Hat OpenShift のデフォルトのコンポーネント (Web コンソールや OperatorHub など) にアクセスするには、ワーカー・ノードをデプロイする VPC サブネットにパブリック・ゲートウェイを接続する必要があります。 パブリック・ゲートウェイを接続したサブネットのワーカー・ノードでは、すべての送信が許可されるようになります。ただし、受信は引き続きすべてブロックされます。

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

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

ネットワーク・セグメンテーションとは何ですか?

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

Red Hat OpenShift on IBM Cloud には、ワーカー・ノードのために高品質のネットワーク・パフォーマンスとネットワークの分離を実現する 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 ソリューションを選択できます。

経路を使用したアプリの安全な公開

インターネットからのネットワーク・トラフィックの着信を許可したい場合は、 routesを使ってアプリを公開することができる。

すべての Red Hat OpenShift クラスターには、一意のドメイン名が割り当てられ、TLS証明書で保護された Red Hat OpenShift ルーターが自動的にセットアップされます。 経路を使用してアプリを公開すると、Red Hat OpenShift ルーターから URL がアプリに割り当てられます。

アプリの経路を作成する場合は、保護された (HTTPS) 経路または非セキュア (HTTP) 経路のどちらを作成するかを決定できます。 保護された経路の場合、ルーターやポッドなど、TLS 終端処理を実装する場所を決定できます。 詳しくは、経路を使用したアプリの公開を参照してください。

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

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

セキュリティ・グループを使ってクラスタのネットワーク・トラフィックを管理できますか？

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

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

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

LoadBalancer、IngressサービスでTLSターミネーションを行うには？

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

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

シングルテナントとマルチテナント、どちらを設定すべきでしょうか？

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

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

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

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

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

シングル・テナント・クラスターとマルチテナント・クラスターのコストはほぼ同じですが、シングル・テナント・クラスターのほうが、マルチテナント・クラスターのプロジェクトよりも高い分離レベルを提供します。 高いワークロード分離が必要な場合は、シングル・テナント・クラスターを使用してください。

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

ポッドのパーミッションをコントロールするには？

プロジェクト内またはプロジェクト間でポッド権限を制御するために、Red Hat OpenShift on IBM Cloud はセキュリティー・コンテキスト制約 (SCC) を使用します。 デフォルトで、すべてのクラスターに、Red Hat OpenShift の SCC と IBM 提供の SCC のセットがセットアップされるので、これらをサービス・アカウント、ポッド、デプロイメント、またはプロジェクトに割り当ててクラスター内の権限を制限できます。 SCC を明示的に割り当てない場合、ポッドは restricted SCC を使用します。Red Hat OpenShift SCC は、コミュニティー Kubernetes クラスターのデフォルトのポッド・セキュリティー・ポリシーよりも厳格です。 コミュニティー Kubernetes クラスターで実行されるアプリを Red Hat OpenShift で実行するには、変更が必要になる場合があります。 詳しくは、セキュリティー・コンテキスト制約の構成を参照してください。

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

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

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

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

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

デフォルトの セキュリティ・コンテキスト制約をカスタマイズして、コンテナ内で実行できるユーザーIDとグループID、またはボリューム・マウント・パスを所有するユーザーIDとグループIDを制御できます。 特定のユーザー ID を設定すると、最小特権モデルが円滑化されます。 セキュリティー・コンテキストによってユーザーが指定されない場合、Kubernetes は、コンテナー・イメージで指定されているユーザーを自動的に使用します。 詳しくは、セキュリティー・コンテキスト制約の構成を参照してください。

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

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