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

17.5. セキュリティー

17.5.1. セキュリティーの基礎
リンクのコピー

セキュリティーは、特にクラウドネイティブアプリケーションを実行する場合、OpenShift Container Platform デプロイメントの重要なコンポーネントです。

セキュリティーに関する重要な考慮事項 に従い、帯域幅の高いネットワーク展開のためにセキュリティーを強化できます。これらの標準とベストプラクティスを実装することで、ほとんどのユースケースでセキュリティーを強化できます。

17.5.1.1. RBAC の概要
リンクのコピー

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

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

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

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

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

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

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

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

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

注記

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

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

RBAC の運用上の考慮事項

操作のオーバーヘッドを削減するには、複数のクラスターで個別のユーザー ID を処理するのではなく、グループを介してアクセスを管理します。組織レベルでグループを管理することで、アクセス制御を合理化し、組織全体の管理を簡素化できます。

17.5.1.2. セキュリティーアカウントの概要
リンクのコピー

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

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

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

17.5.1.3. アイデンティティープロバイダーの設定
リンクのコピー

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

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

注記

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

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

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

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

17.5.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>
    Copy to Clipboard Toggle word wrap

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

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

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

      $ oc whoami
      Copy to Clipboard Toggle word wrap

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

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

    注記

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

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

    $ oc delete secrets kubeadmin -n kube-system
    Copy to Clipboard Toggle word wrap

17.5.1.5. セキュリティーに関する考慮事項
リンクのコピー

ワークロードは機密データを処理し、需要の高い信頼性が高くなる可能性があります。セキュリティー脆弱性が 1 つあると、クラスター全体にわたるセキュリティーが広範囲に及ぶ可能性があります。OpenShift Container Platform クラスターで多数のコンポーネントが実行されているため、各コンポーネントのセキュリティーを確保して、違反のエスカレートを防ぐ必要があります。すべてのコンポーネントを含むインフラストラクチャー全体でセキュリティーを確保することは、ネットワークの整合性を維持し、脆弱性を回避するために不可欠です。

以下の主要なセキュリティー機能は、機密データを処理するすべての業界に不可欠です。

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

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

17.5.1.7. ベアメタルインフラストラクチャー
リンクのコピー

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

17.5.1.8. ライフサイクル管理
リンクのコピー

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

ライフサイクル管理およびアップグレードの詳細は、OpenShift Container Platform クラスターのアップグレードを参照してください。

17.5.2. ホストのセキュリティー
リンクのコピー

17.5.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 はアクセスを拒否します。詳細は、SELinux の概要 を参照してください。

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

17.5.2.2. コマンドラインからのホストへのアクセス
リンクのコピー

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

重要

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

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

デバッグ Pod の使用

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

$ oc debug node/<worker_node_name>
Copy to Clipboard Toggle word wrap

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

# chroot /host
Copy to Clipboard Toggle word wrap

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

直接 SSH 接続

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

$ ssh core@<worker_node_name>
Copy to Clipboard Toggle word wrap
重要

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

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

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

$ sudo -i
Copy to Clipboard Toggle word wrap
コンソールアクセス

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

注記

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

17.5.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 機能 の man ページを参照してください。https://man7.org/linux/man-pages/man7/capabilities.7.html

17.5.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
Copy to Clipboard Toggle word wrap

+ 出力例 

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>
Copy to Clipboard Toggle word wrap

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

Theme

© 2025 Red Hat