17.5. セキュリティー

ロールベースアクセス制御 (RBAC) オブジェクトは、ユーザーがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。

これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、OpenShift Container Platform プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。

開発者はローカルロールとバインディングを使用して、プロジェクトにアクセスできるユーザーを制御できます。認可は認証とは異なる手順であることに注意してください。認証はアクションを実行するユーザーのアイデンティティーの判別により密接に関連しています。

認可は、次の認可オブジェクトを使用して管理されます。

RBAC の詳細は、「RBAC を使用した権限の定義および適用」を参照してください。

RBAC の運用上の考慮事項

運用上のオーバーヘッドを削減するには、複数のクラスターにわたって個々のユーザー ID を処理するのではなく、グループを通じてアクセスを管理することが重要です。組織レベルでグループを管理することで、アクセス制御を合理化し、組織全体の管理を簡素化できます。

サービスアカウントは、コンポーネントが API に直接アクセスできるようにする OpenShift Container Platform アカウントです。サービスアカウントは各プロジェクトに存在する API オブジェクトです。サービスアカウントは、一般ユーザーの認証情報を共有せずに API アクセスをより柔軟に制御する方法を提供します。

サービスアカウントを使用すると、Pod にロールベースのアクセス制御 (RBAC) を適用できます。Pod やデプロイメントなどのワークロードにサービスアカウントを割り当てることで、さまざまなレジストリーからのプルなど、追加の権限を付与できます。これにより、より低い権限をサービスアカウントに割り当てて、そのアカウント配下で実行される Pod のセキュリティー関連のフットプリントを削減することもできます。

サービスアカウントの詳細は、「サービスアカウントの概要および作成」を参照してください。

アイデンティティープロバイダーの設定は、クラスターでユーザーを設定する際の最初のステップです。アイデンティティープロバイダーを使用すると、組織レベルでグループを管理できます。

アイデンティティープロバイダーは、クラスターレベルではなく組織レベルで管理される特定のユーザーグループを取得できます。これにより、組織の確立されたプラクティスに準拠したグループにユーザーを追加したり、グループからユーザーを削除したりできます。

アイデンティティープロバイダーを使用すると、組織内の特定グループのアクセスレベルを管理できます。たとえば、アクセスレベルを管理するために、次の操作を実行できます。

アイデンティティープロバイダーの設定の詳細は、「アイデンティティープロバイダー設定について」を参照してください。

デフォルトでは、すべてのクラスターに cluster-admin 権限を持つ kubeadmin ユーザーが作成されます。クラスターのセキュリティーを強化するには、`kubeadmin` ユーザーを cluster-admin ユーザーに置き換えてから、kubeadmin ユーザーを無効にするか削除します。

通信事業者のワークロードは膨大な量の機密データを処理するため、高い信頼性が求められます。1 つのセキュリティー脆弱性が、クラスター全体に及ぶ広範な侵害につながる可能性があります。シングルノード OpenShift クラスター上で多数のコンポーネントが実行されている場合、侵害が拡大するのを防ぐために各コンポーネントを保護する必要があります。通信事業者のネットワークの信頼性を維持し、脆弱性を回避するには、すべてのコンポーネントを含むインフラストラクチャー全体のセキュリティーを確保することが不可欠です。

通信事業者にとっては、以下の主要なセキュリティー機能が欠かせません。

Kubernetes では当初、Pod のセキュリティーが制限されていました。OpenShift Container Platform を Kubernetes と統合したときに、Red Hat は Security Context Constraints (SCC) によって Pod のセキュリティーを強化しました。同様の機能として、Kubernetes バージョン 1.3 で PodSecurityPolicy (PSP) が導入されました。しかし、Kubernetes バージョン 1.21 で Pod Security Admission (PSA) が導入されたことにより、Kubernetes バージョン 1.25 で PSP は非推奨になりました。

PSA は、OpenShift Container Platform でも、バージョン 4.11 で利用可能になりました。PSA は、Pod のセキュリティーを強化しますが、通信事業者のユースケースに現在も必要な、SCC によって提供される一部の機能が欠けています。したがって、OpenShift Container Platform は引き続き PSA と SCC の両方をサポートしています。

クラウドネイティブネットワーク機能 (CNF) のデプロイメントには、次の主な領域があります。

セキュリティーを確保するには、アップグレードが重要です。脆弱性が発見された場合、その脆弱性は最新の z-stream リリースで修正されます。その後、この修正は下位の各 y-stream リリースに遡って導入され、サポート対象のすべてのバージョンにパッチが適用されます。パッチはサポート対象外になったリリースには適用されません。したがって、OpenShift Container Platform クラスターを定期的にアップグレードして、サポート対象のリリースを維持し、脆弱性から保護された状態を維持することが重要です。

ライフサイクル管理とアップグレードの詳細は、「通信事業者コア CNF クラスターのアップグレード」を参照してください。

ネットワーク機能 (NF) は、独立して動作する専用のハードウェアデバイスである物理ネットワーク機能 (PNF) として初まりました。PNF は仮想ネットワーク機能 (VNF) へと徐々に進化しました。VNF は、PNF の機能を仮想化する一方で、CPU、メモリー、ストレージ、ネットワークなどのリソースを制御します。

テクノロジーがさらに進歩するにつれて、VNF はクラウドネイティブネットワーク機能 (CNF) に移行しました。CNF は軽量でセキュアかつスケーラブルなコンテナー内で実行されます。セキュリティーとパフォーマンスを強化するために、非 root での実行や最小限のホスト干渉など、厳格な制限が適用されます。

PNF は、干渉を受けることなく独立して動作するように、無制限の root アクセス権を持っていました。VNF への移行に伴い、リソースの使用が制御されるようになりましたが、プロセスは仮想マシン内で引き続き root として実行できました。一方、CNF は root アクセスを制限し、コンテナーの機能を制限して、他のコンテナーやホストオペレーティングシステムへの干渉を防ぎます。

CNF への移行における主な課題としては、次のものがあります。