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

第15章 Security Context Constraints の管理

OpenShift Container Platform では、Security Context Constraint (SCC) を使用して、クラスター内の Pod のアクセス許可を制御できます。

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

重要

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

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

15.1. Security Context Constraints について

RBAC リソースがユーザーアクセスを制御するのと同じ方法で、管理者は Security Context Constraints (SCC) を使用して Pod のパーミッションを制御できます。これらのアクセス許可によって、Pod が実行できるアクションとアクセスできるリソースが決まります。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行に関する条件の一覧を定義できます。

管理者は Security Context Constraints で、以下を制御できます。

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

OpenShift Container Platform のネームスペースにopenshift.io/run-levelラベルを設定しないでください。このラベルは、Kubernetes API サーバーや OpenShift API サーバーなどの主要な API グループの起動を管理するために内部 OpenShift Container Platform コンポーネントで使用されます。openshift.io/run-level ラベルが設定される場合には、対象の namespace の Pod に SCC が適用されず、その namespace で実行されるワークロードには高度な特権が割り当てられます。

15.1.1. デフォルトの Security Context Constraints

クラスターには、以下の表で説明されているように、デフォルトの SCC (Security Context Constraints) が複数含まれます。オペレーターまたはその他のコンポーネントを OpenShift Container Platform にインストールすると、追加の SCC がインストールされる場合があります。

重要

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

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

表15.1 デフォルトの Security Context Constraints
Security context constraint (SCC)説明

anyuid

SCC のすべての機能が restricted で提供されますが、ユーザーは任意の UID と GID で実行できます。

hostaccess

ホストの全 namespace にアクセスできますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。

警告

この SCC で、ホストは namespace、ファイルシステム、および PID にアクセスできます。信頼できる Pod だけがこの SCC を使用する必要があります。付与には注意が必要です。

hostmount-anyuid

SCC のすべての機能を restricted で提供しますが、ホストのマウントとシステム上の任意の UID および GID として実行できます。

警告

この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。

hostnetwork

ホストのネットワークおよびホストポートを使用できますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。

警告

追加のワークロードをコントロールプレーンホストで実行する場合は、hostnetwork へのアクセスを割り当てるときに注意してください。コントロールプレーンホストで hostnetwork を実行するワークロードにはクラスター上で root アクセスを持つユーザーと同じ機能があるため、適切に信頼されている必要があります。

hostnetwork-v2

hostnetwork SCC と似ていますが、次の違いがあります。

  • ALL 機能がコンテナーから削除されます。
  • NET_BIND_SERVICE 機能を明示的に追加できます。
  • seccompProfile はデフォルトで runtime/default に設定されています。
  • セキュリティーコンテキストでは、allowPrivilegeEscalation を設定解除するか、false に設定する必要があります。

node-exporter

Prometheus ノードエクスポーターに使用されます。

警告

この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。

nonroot

SCC のすべての機能が restricted で提供されますが、ユーザーは root 以外の UID で実行できます。ユーザーは UID を指定するか、コンテナーランタイムのマニフェストに指定する必要があります。

nonroot-v2

nonroot SCC と同様ですが、次の違いがあります。

  • ALL 機能がコンテナーから削除されます。
  • NET_BIND_SERVICE 機能を明示的に追加できます。
  • seccompProfile はデフォルトで runtime/default に設定されています。
  • セキュリティーコンテキストでは、allowPrivilegeEscalation を設定解除するか、false に設定する必要があります。

privileged

すべての特権およびホスト機能にアクセスでき、任意のユーザー、任意のグループ、FSGroup、および任意の SELinux コンテキストで実行できます。

警告

これは最も制限の少ない SCC であり、クラスター管理にのみ使用してください。付与には注意が必要です。

privileged SCC は以下を許可します。

  • ユーザーによる特権付き Pod の実行
  • Pod によるホストディレクトリーのボリュームとしてのマウント
  • Pod の任意ユーザーとしての実行
  • Pod の MCS ラベルの使用による実行
  • Pod によるホストの IPC namespace の使用
  • Pod によるホストの PID namespace の使用
  • Pod による FSGroup の使用
  • Pod による補助グループの使用
  • Pod による seccomp プロファイルの使用
  • Pod による機能の要求
注記

Pod の仕様で privileged: true を設定しても、privileged SCC が選択されるとは限りません。ユーザーに使用権限がある場合に、allowPrivilegedContainer: true が指定されており、優先順位が最も高い SCC が選択されます。

restricted

すべてのホスト機能へのアクセスが拒否され、Pod を UID および namespace に割り当てられる SELinux コンテキストで実行する必要があります。

restricted SCC は以下を実行します。

  • Pod が特権付きで実行されないようにします。
  • Pod がホストディレクトリーボリュームをマウントできないようにします。
  • Pod が事前に割り当てられた UID 範囲のユーザーとして実行することを要求します。
  • Pod が事前に割り当てられた MCS ラベルで実行されることを要求します。
  • Pod が事前に割り当てられた FSGroup で実行されることを要求します。
  • Pod が補助グループを使用することを許可します。

4.10 以前の OpenShift Container Platform からアップグレードされたクラスターでは、認証済みのユーザーであれば、この SCC を利用できます。アクセスが明示的に付与されない限り、新しい OpenShift Container Platform 4.11 以降のインストールのユーザーは restricted SCC を使用できなくなります。

restricted-v2

restricted SCC と同様ですが、次の違いがあります。

  • ALL 機能がコンテナーから削除されます。
  • NET_BIND_SERVICE 機能を明示的に追加できます。
  • seccompProfile はデフォルトで runtime/default に設定されています。
  • セキュリティーコンテキストでは、allowPrivilegeEscalation を設定解除するか、false に設定する必要があります。

これは新規インストールで提供され、デフォルトで認証済みユーザーに使用される最も制限の厳しい SCC です。

注記

restricted-v2 SCC は、システムにデフォルトで含まれている SCC の中で最も制限が厳しいものです。ただし、さらに制限の厳しいカスタム SCC を作成できます。たとえば、readOnlyRootFilesystem を true に制限する SCC を作成できます。

15.1.2. Security Context Constraints の設定

Security Context Constraints (SCC) は、Pod がアクセスできるセキュリティー機能を制御する設定およびストラテジーで構成されています。これらの設定は以下のカテゴリーに分類されます。

カテゴリー説明

ブール値による制御

このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、AllowPrivilegedContainer が指定されていない場合は、false に常に設定されます。

許可されるセットによる制御

このタイプのフィールドがセットに対してチェックされ、その値が許可されることを確認します。

ストラテジーによる制御

値を生成するストラテジーを持つ項目は以下を提供します。

  • 値を生成するメカニズム
  • 指定された値が許可される値のセットに属するようにするメカニズム

CRI-O には、Pod の各コンテナーについて許可されるデフォルトの機能リストがあります。

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

コンテナーはこのデフォルトリストから機能を使用しますが、Pod マニフェストの作成者は追加機能を要求したり、デフォルト動作の一部を削除してリストを変更できます。allowedCapabilities パラメーター、defaultAddCapabilities パラメーター、および requiredDropCapabilities パラメーターを使用して、Pod からのこのような要求を制御します。これらのパラメーターを使用して、(各コンテナーに追加する必要のある機能や、各コンテナーから禁止または破棄する必要のあるものなど) 要求できる機能を指定できます。

注記

requiredDropCapabilities パラメーターを ALL に設定すると、すべての capabilites をコンテナーから取り除くことができます。これは、restricted-v2 SCC の機能です。

15.1.3. Security Context Constraints ストラテジー

RunAsUser

  • MustRunAs: runAsUser が設定されることを要求します。デフォルトで設定済みの runAsUser を使用します。設定済みの runAsUser に対して検証します。

    MustRunAs スニペットの例

    ...
runAsUser:
  type: MustRunAs
  uid: <id>
...

  • MustRunAsRange: 事前に割り当てられた値を使用していない場合に、最小値および最大値が定義されることを要求します。デフォルトでは最小値を使用します。許可される範囲全体に対して検証します。

    MustRunAsRange スニペットの例

    ...
runAsUser:
  type: MustRunAsRange
  uidRangeMax: <maxvalue>
  uidRangeMin: <minvalue>
...

  • MustRunAsNonRoot: Pod がゼロ以外の runAsUser で送信されること、または USER ディレクティブをイメージに定義することを要求します。デフォルトは指定されません。

    MustRunAsNonRoot スニペットの例

    ...
runAsUser:
  type: MustRunAsNonRoot
...

  • RunAsAny: デフォルトは指定されません。runAsUser の指定を許可します。

    RunAsAny スニペットの例

    ...
runAsUser:
  type: RunAsAny
...

SELinuxContext

  • MustRunAs: 事前に割り当てられた値を使用していない場合に seLinuxOptions が設定されることを要求します。デフォルトとして seLinuxOptions を使用します。seLinuxOptions に対して検証します。
  • RunAsAny: デフォルトは指定されません。seLinuxOptions の指定を許可します。

SupplementalGroups

  • MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。すべての範囲に対して検証します。
  • RunAsAny: デフォルトは指定されません。supplementalGroups の指定を許可します。

FSGroup

  • MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。最初の範囲の最初の ID に対して検証します。
  • RunAsAny: デフォルトは指定されません。fsGroup ID の指定を許可します。

15.1.4. ボリュームの制御

特定のボリュームタイプの使用は、SCC の volumes フィールドを設定して制御できます。

このフィールドの許容値は、ボリュームの作成時に定義されるボリュームソースに対応します。

新規 SCC について許可されるボリュームの推奨される最小セットは、configMap、downwardAPI、emptyDir、persistentVolumeClaim, secret、および projected です。

注記

許可されるボリュームタイプのリストは、新規タイプが OpenShift Container Platform の各リリースと共に追加されるため、網羅的なリストである必要はありません。

注記

後方互換性を確保するため、allowHostDirVolumePlugin の使用は volumes フィールドの設定をオーバーライドします。たとえば、allowHostDirVolumePlugin が false に設定されていて、volumes フィールドで許可されている場合は、volumes から hostPath 値が削除されます。

15.1.5. アドミッション制御

SCC が設定された アドミッション制御 により、ユーザーに付与された機能に基づいてリソースの作成に対する制御が可能になります。

SCC の観点では、これはアドミッションコントローラーが、SCC の適切なセットを取得するためにコンテキストで利用可能なユーザー情報を検査できることを意味します。これにより、Pod はその運用環境に関する要求を行ったり、Pod に適用する一連の制約を生成したりする権限が与えられます

アドミッションが Pod を許可するために使用する SCC のセットはユーザーアイデンティティーおよびユーザーが属するグループによって決定されます。さらに、Pod がサービスアカウントを指定する場合は、許可される SCC のセットに、サービスアカウントでアクセスできる制約が含まれます。

注記

デプロイメントなどのワークロードリソースを作成する場合、SCC の検索と、作成された Pod の許可には、サービスアカウントのみが使用されます。

アドミッションは以下の方法を使用して、Pod の最終的なセキュリティーコンテキストを作成します。

  1. 使用できるすべての SCC を取得します。
  2. 要求に指定されていないセキュリティーコンテキストに、設定のフィールド値を生成します。
  3. 利用可能な制約に対する最終的な設定を検証します。

制約の一致するセットが検出される場合は、Pod が受け入れられます。要求が SCC に一致しない場合は、Pod が拒否されます。

Pod はすべてのフィールドを SCC に対して検証する必要があります。以下は、検証する必要がある 2 つのフィールドの例です。

注記

これらの例は、事前に割り当てられた値を使用するストラテジーに関連します。

MustRunAs の FSGroup SCC ストラテジー

Pod が fsGroup ID を定義する場合、その ID はデフォルトの fsGroup ID と同一にする必要があります。そうでない場合は、Pod が SCC で検証されず、次の SCC が評価されます。

SecurityContextConstraints.fsGroup フィールドに値 RunAsAny があり、Pod 仕様で Pod.spec.securityContext.fsGroup が省略されると、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。

MustRunAs の SupplementalGroups SCC ストラテジー

Pod 仕様が 1 つ以上の supplementalGroups ID を定義する場合、Pod の ID は namespace の openshift.io/sa.scc.supplemental-groups アノテーションの ID のいずれかと同一にする必要があります。そうでない場合は、Pod が SCC で検証されず、次の SCC が評価されます。

SecurityContextConstraints.supplementalGroups フィールドに値 RunAsAny があり、Pod 仕様が Pod.spec.securityContext.supplementalGroups を省略する場合、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。

15.1.6. Security Context Constraints の優先度設定

SCC (Security Context Constraints) には優先度フィールドがあり、アドミッションコントローラーの要求検証を試行する順序に影響を与えます。

優先順位値 0 は可能な限り低い優先順位です。nil 優先順位は 0 または最低の優先順位とみなされます。優先順位の高い SCC は、並べ替え時にセットの先頭に移動します。

使用可能な SCC の完全なセットが決定すると、SCC は次の方法で順序付けられます。

  1. 最も優先度の高い SCC が最初に並べられます。
  2. 優先度が等しいと、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
  3. 優先度と制限の両方が等しいと、SCC は名前でソートされます。

デフォルトで、クラスター管理者に付与される anyuid SCC には SCC セットの優先度が指定されます。これにより、クラスター管理者は Pod の SecurityContext で RunAsUser を指定することにより、任意のユーザーとして Pod を実行できます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.