サポートコンソール開発者トライアルの開始お問い合わせ

16.4. セキュリティー

16.4.1. セキュリティーの基礎

セキュリティーは、特にクラウドネイティブネットワーク機能 (CNF) を実行する場合、OpenShift Container Platform 上の通信事業者デプロイメントの重要な要素となります。

セキュリティー上の重要な考慮事項を遵守することで、通信事業者 (telco) 環境における高帯域幅ネットワークデプロイメントのセキュリティーを強化できます。このような標準やベストプラクティスを実装すると、通信事業者固有のユースケースにおけるセキュリティーを強化できます。

16.4.1.1. RBAC の概要

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

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

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

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

ルール
特定のオブジェクトに対して許可されるアクションのセットです。たとえば、ルールによって、ユーザーまたはサービスアカウントが Pod を作成できるかどうかを決定できます。各ルールで、API リソース、その API 内のリソース、および許可されるアクションを指定します。
ロール

ユーザーまたはグループが実行できるアクションを定義するルールの集まりです。ルールを複数のユーザーまたはグループに関連付けたり、バインドしたりできます。ロールファイルに、そのロールに許可されるアクションおよびリソースを指定するルールを 1 つ以上含めることができます。

ロールは次のタイプに分類されます。

  • クラスターロール: クラスターレベルでクラスターロールを定義できます。クラスターロールは 1 つの namespace に結び付けられません。ユーザー、グループ、またはサービスアカウントにクラスターロールをバインドすると、すべての namespace または特定の namespace に適用できます。
  • プロジェクトロール: 特定の namespace 内にプロジェクトロールを作成できます。プロジェクトロールはその namespace にのみ適用されます。特定のユーザーに権限を割り当てて、ロールとロールバインディングをそのロールの namespace 内に作成することで、他の namespace に影響を与えないようにすることができます。
バインディング

ロールを使用したユーザーやグループ間の関連付けです。ロールバインディングを作成すると、ロール内のルールを特定のユーザー ID またはグループと結び付けることができます。これにより、ロールとユーザーまたはグループが組み合わせられ、ユーザーまたはグループが実行できるアクションが定義されます。

注記

ユーザーまたはグループには複数のロールをバインドできます。

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

RBAC の運用上の考慮事項

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

関連情報

16.4.1.2. セキュリティーアカウントの概要

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

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

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

関連情報

16.4.1.3. アイデンティティープロバイダーの設定

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

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

注記

変更をクラスターに取り込むには、頻繁に実行される cron ジョブを設定する必要があります。

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

  • クラスターレベルの権限を必要とするチームに cluster-admin ロールを割り当てる。
  • アプリケーション管理者に、それぞれのプロジェクトのみを管理するための特定の権限を付与する。
  • 運用チームに、クラスター全体の view アクセス権を提供し、変更を許可することなく、監視できるようにする。

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

関連情報

16.4.1.4. kubeadmin ユーザーを cluster-admin ユーザーに置き換える

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

前提条件

  • cluster-admin 権限を持つユーザーを作成した。
  • OpenShift CLI (oc) がインストールされている。
  • セキュアに保存するための仮想 vault への管理アクセス権がある。

手順

  1. htpasswd アイデンティティープロバイダーを使用して、緊急用の cluster-admin ユーザーを作成します。詳細は、「htpasswd 認証について」を参照してください。

  2. 次のコマンドを実行して、新しいユーザーに cluster-admin 権限を割り当てます。 

    $ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>

  3. 緊急用ユーザーのアクセス権を検証します。

    1. 新しい緊急用ユーザーを使用してクラスターにログインします。

    2. 次のコマンドを実行して、ユーザーに cluster-admin 権限があることを確認します。 

      $ oc whoami

      出力に緊急用ユーザーの ID が表示されることを確認します。

  4. 緊急用ユーザーのパスワードまたは認証キーを仮想 vault にセキュアに保存します。

    注記

    機密性の高い認証情報の保護に関する組織のベストプラクティスに従ってください。

  5. 次のコマンドを実行して、kubeadmin ユーザーを無効にするか削除し、セキュリティーリスクを軽減します。 

    $ oc delete secrets kubeadmin -n kube-system

関連情報

16.4.1.5. 通信事業者向け CNF のセキュリティーに関する考慮事項

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

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

  • Security Context Constraints (SCC): OpenShift クラスター内の Pod セキュリティーをきめ細かく制御します。
  • Pod Security Admission (PSA): Kubernetes ネイティブの Pod セキュリティーコントロール。
  • 暗号化: 高スループットのネットワーク環境でデータの機密性を確保します。

16.4.1.6. Kubernetes と OpenShift Container Platform における Pod セキュリティーの発展

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 の両方をサポートしています。

16.4.1.7. CNF デプロイメントの主な領域

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

コア
CNF が初めてデプロイされたのは、ワイヤレスネットワークのコア領域でした。CNF をコアにデプロイするということは、通常、中央オフィスまたはデータセンターにサーバーのラックを配置することを意味します。これらのサーバーは、インターネットと無線アクセスネットワーク (RAN) の両方に接続されます。ただし、多くの場合、複数のセキュリティーファイアウォールの背後に配置され、インターネットから完全に遮断されていることもあります。このタイプのセットアップは、オフラインクラスターまたは非接続クラスターと呼ばれます。
RAN
CNF がコアネットワークで問題なくテストされ、効果的であることが確認されたところで、CNF を無線アクセスネットワーク (RAN) にデプロイすることが検討されました。RAN に CNF を導入するには、多数のサーバー (大規模なデプロイメントでは最大 100,000 台) が必要です。これらのサーバーは、携帯電話基地局の近くに設置されます。通常はシングルノード OpenShift クラスターとして実行され、高いスケーラビリティーを必要とします。

16.4.1.8. 通信事業者固有のインフラストラクチャー

ハードウェア要件
通信事業者のネットワークでは、クラスターは主にベアメタルハードウェア上に構築されます。その場合、仮想マシンを使用せずに、オペレーティングシステム (op-system-first) を物理マシンに直接インストールします。これにより、ネットワーク接続の複雑さが軽減され、レイテンシーが最小限に抑えられ、アプリケーションの CPU 使用率が最適化されます。
ネットワーク要件
通信事業者のネットワークでは、標準的な IT ネットワークよりもはるかに大きな帯域幅が必要です。通信事業者のネットワークでは、大量のデータスループットを処理するために、通常、デュアルポート 25 GB 接続または 100 GB ネットワークインターフェイスカード (NIC) が使用されます。セキュリティーは極めて重要であり、機密性の高い個人データを保護するには、暗号化された接続とセキュアなエンドポイントが必要です。

16.4.1.9. ライフサイクル管理

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

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

関連情報

通信事業者向けコア CNF クラスターのアップグレード

16.4.1.10. ネットワーク機能から CNF への進化

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

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

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

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

  • モノリシックなネットワーク機能を、コンテナー化されたより小さなプロセスに分割する。
  • 非 root での実行や分離などのクラウドネイティブの原則に準拠しながら、通信業界グレードのパフォーマンスと信頼性を維持する。

16.4.2. ホストのセキュリティー

16.4.2.1. Red Hat Enterprise Linux CoreOS (RHCOS)

Red Hat Enterprise Linux CoreOS (RHCOS) は、いくつかの重要な点で Red Hat Enterprise Linux (RHEL) と異なります。詳細は、「RHCOS について」を参照してください。

通信事業の観点から見ると、大きな違いは、Machine Config Operator を通じて更新される rpm-ostree の制御です。

RHCOS は、OpenShift Container Platform の Pod に使用されるものと同じイミュータブルな設計に準拠しています。これにより、クラスター全体でオペレーティングシステムの一貫性が維持されます。RHCOS アーキテクチャーの詳細は、「Red Hat Enterprise Linux CoreOS (RHCOS)」を参照してください。

セキュリティーを維持しながらホストを効果的に管理するには、可能な限り直接アクセスを避けてください。代わりに、次の方法を使用してホストを管理できます。

  • デバッグ Pod
  • 直接 SSH 接続
  • コンソールアクセス

次の RHCOS セキュリティーメカニズムを確認してください。いずれもホストのセキュリティーを維持するために不可欠なものです。

Linux 名前空間
プロセスとリソースの分離を実現します。各コンテナーは、独自の名前空間内にプロセスとファイルを保持します。ユーザーがコンテナーの名前空間から脱出すると、ユーザーがホストオペレーティングシステムにアクセスできるようになり、セキュリティーが侵害される可能性があります。
Security-Enhanced Linux (SELinux)

必須アクセス制御を適用し、プロセスによるファイルとディレクトリーへのアクセスを制限します。プロセスが制限を破ろうとした場合にファイルへの不正アクセスを防止することにより、セキュリティー層をさらに追加します。

SELinux は、明示的に許可されない限りすべてを拒否するというセキュリティーポリシーに従います。プロセスが許可なくファイルを変更またはアクセスしようとすると、SELinux はアクセスを拒否します。詳細は、SELinux の概要 を参照してください。

Linux ケイパビリティー
プロセスに特定の権限を細かいレベルで割り当てることで、フル root 権限の必要性を最小限に抑えます。詳細は、「Linux ケイパビリティー」を参照してください。
コントロールグループ (cgroup)
プロセスやコンテナーの CPU やメモリーなどのシステムリソースを割り当てて管理し、効率的な使用を実現します。OpenShift Container Platform 4.16 以降、cgroups には 2 つのバージョンがあります。デフォルトでは cgroup v2 が設定されます。
CRI-O
セキュリティー境界を適用し、コンテナーのワークロードを管理する軽量のコンテナーランタイムとして機能します。

関連情報

16.4.2.2. コマンドラインからのホストへのアクセス

ホストの変更やアクセスすべきでない Pod へのアクセスを避けるために、ホストへの直接アクセスを制限する必要があります。ホストに直接アクセスする必要があるユーザーについては、LDAP を使用した SSSD などの外部オーセンティケーターを使用してアクセスを管理することを推奨します。これにより、Machine Config Operator を通じてクラスター全体の一貫性を維持できます。

重要

OpenShift Container Platform クラスターサーバーで root ID への直接アクセスを設定しないでください。

クラスター内のノードに接続するには、次の方法を使用できます。

デバッグ Pod の使用

これは推奨されるノードへのアクセス方法です。ノードをデバッグまたは接続するには、次のコマンドを実行します。 

$ oc debug node/<worker_node_name>

ノードに接続した後、次のコマンドを実行してルートファイルシステムにアクセスします。 

# chroot /host

これにより、ノード上のデバッグ Pod 内で root アクセスが可能になります。詳細は、「root アクセスでのデバッグ Pod の起動」を参照してください。

直接 SSH 接続

root ユーザーの使用は避けてください。代わりに、コアユーザー ID (または独自の ID) を使用してください。SSH を使用してノードに接続するには、次のコマンドを実行します。 

$ ssh core@<worker_node_name>
重要

コアユーザー ID には、最初にクラスター内で sudo 権限が付与されます。

SSH を使用してノードに接続できない場合は、How to connect to OpenShift Container Platform 4.x Cluster nodes using SSH bastion pod を参照して、SSH 鍵をコアユーザーに追加してください。

SSH を使用してノードに接続した後、次のコマンドを実行して root シェルにアクセスします。 

$ sudo -i
コンソールアクセス

コンソールがセキュアであることを確認してください。root ID による直接ログインを許可しないでください。代わりに個別の ID を使用します。

注記

コンソールアクセスの保護に関する組織のベストプラクティスに従ってください。

関連情報

16.4.2.3. Linux ケイパビリティー

Linux ケイパビリティーは、プロセスがホストシステム上で実行できるアクションを定義するものです。デフォルトでは、セキュリティー対策が適用されない限り、いくつかのケイパビリティーが Pod に付与されます。これらのデフォルトのケイパビリティーは次のとおりです。

  • CHOWN
  • DAC_OVERRIDE
  • FSETID
  • FOWNER
  • SETGID
  • SETUID
  • SETPCAP
  • NET_BIND_SERVICE
  • KILL

Security Context Constraints (SCC) を設定することで、Pod に付与されるケイパビリティーを変更できます。

重要

次のケイパビリティーを Pod に割り当てることはできません。

  • SYS_ADMIN: 昇格された権限を付与する強力なケイパビリティー。このケイパビリティーを許可すると、セキュリティー境界が破られ、重大なセキュリティーリスクが生じる可能性があります。
  • NET_ADMIN: SR-IOV ポートなどのネットワークを制御できます。ただし、最新のセットアップでは代替ソリューションに置き換えることができます。

Linux ケイパビリティーの詳細は、Linux capabilities man ページを参照してください。

16.4.3. Security Context Constraints

RBAC リソースがユーザーアクセスを制御するのと同様の方法で、管理者は Security Context Constraints (SCC) を使用して Pod の権限を制御できます。この権限によって、Pod が実行できるアクションとアクセスできるリソースが決まります。SCC を使用すると、Pod が実行する必要がある一連の条件を定義できます。

Security Context Constraints を使用すると、管理者は次のセキュリティー制約を制御できます。

  • Pod が allowPrivilegedContainer フラグが付いた特権付きコンテナーを実行できるかどうか
  • Pod が allowPrivilegeEscalation フラグで制約されているかどうか
  • コンテナーが要求できる機能
  • ホストディレクトリーのボリュームとしての使用
  • コンテナーの SELinux コンテキスト
  • コンテナーのユーザー ID
  • ホストの namespace とネットワークの使用
  • Pod ボリュームを所有する FSGroup の割り当て
  • 許可される補助グループの設定
  • コンテナーが root ファイルシステムへの書き込みアクセスを必要とするかどうか
  • ボリュームタイプの使用
  • 許可される seccomp プロファイルの設定

デフォルトの SCC は、インストール中、および一部の Operator またはその他のコンポーネントをインストールするときに作成されます。クラスター管理者は、OpenShift CLI (oc) を使用して独自の SCC を作成することもできます。

デフォルトの Security Context Constraints の詳細は、デフォルトの Security Context Constraints を参照してください。

重要

デフォルトの SCC は変更しないでください。デフォルトの SCC をカスタマイズすると、プラットフォームの Pod をデプロイ時または OpenShift Container Platform のアップグレード時に問題が発生する可能性があります。さらに、一部のクラスターのアップグレード中にデフォルトの SCC 値がデフォルトにリセットされ、それらの SCC に対するすべてのカスタマイズが破棄されます。

デフォルトの SCC を変更する代わりに、必要に応じて独自の SCC を作成および変更します。詳細な手順は、Security Context Constraints の作成 を参照してください。

次の基本的な SCC を使用できます。

  • restricted
  • restricted-v2

restricted-v2 SCC は、新規インストールによって提供される最も制限の厳しい SCC であり、認証されたユーザーにデフォルトで使用されます。これは、Pod Security Admission (PSA) の制限と同等であり、オリジナルの restricted SCC よりも制限が厳しいため、セキュリティーが強化されます。また、複数のリリースにわたってオリジナルの SCC から v2 に移行する際に有用です。最終的には、オリジナルの SCC は非推奨になります。したがって、restricted-v2 SCC を使用することを推奨します。

次のコマンドを実行すると、restricted-v2 SCC を調べることができます。 

$ oc describe scc restricted-v2

出力例

Name:                                           restricted-v2
Priority:                                       <none>
Access:
  Users:                                        <none>
  Groups:                                       <none>
Settings:
  Allow Privileged:                             false
  Allow Privilege Escalation:                   false
  Default Add Capabilities:                     <none>
  Required Drop Capabilities:                   ALL
  Allowed Capabilities:                         NET_BIND_SERVICE
  Allowed Seccomp Profiles:                     runtime/default
  Allowed Volume Types:                         configMap,downwardAPI,emptyDir,ephemeral,persistentVolumeClaim,projected,secret
  Allowed Flexvolumes:                          <all>
  Allowed Unsafe Sysctls:                       <none>
  Forbidden Sysctls:                            <none>
  Allow Host Network:                           false
  Allow Host Ports:                             false
  Allow Host PID:                               false
  Allow Host IPC:                               false
  Read Only Root Filesystem:                    false
  Run As User Strategy: MustRunAsRange
    UID:                                        <none>
    UID Range Min:                              <none>
    UID Range Max:                              <none>
  SELinux Context Strategy: MustRunAs
    User:                                       <none>
    Role:                                       <none>
    Type:                                       <none>
    Level:                                      <none>
  FSGroup Strategy: MustRunAs
    Ranges:                                     <none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:                                     <none>

restricted-v2 SCC は、明示的に許可されているもの以外はすべて明示的に拒否します。次の設定により、許可されるケイパビリティーとセキュリティー制限が定義されます。

  • Default add capabilities: <none> に設定されています。つまり、デフォルトでは Pod にケイパビリティーが追加されません。
  • Required drop capabilities: ALL に設定されています。これにより、Pod のデフォルトの Linux ケイパビリティーがすべて削除されます。
  • Allowed capabilities: NET_BIND_SERVICE。Pod はこのケイパビリティーを要求できますが、デフォルトでは追加されません。
  • Allowed seccomp profiles: runtime/default。

詳細は、Security Context Constraints の管理 を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.