検索

27.18.2. SCC、デフォルト値および許可される範囲

download PDF

SCC は、デフォルトのユーザー ID、fsGroup ID、補助グループ ID、および SELinux ラベルが Pod に割り当てられるかどうかに影響します。また、Pod 定義 (またはイメージ) で指定される ID が許容可能な ID の範囲に対して検証されるかどうかにも影響します。検証が必要な場合で検証が失敗すると、Pod も失敗します。

SCC は、runAsUsersupplementalGroupsfsGroup などのストラテジーを定義します。これらのストラテジーは Pod が承認されるかどうかを判断するのに役立ちます。RunAsAny に設定されるストラテジーの値は、Pod がそのストラテジーに関して必要なことを何でも実行できるということを実質的に宣言するものです。そのストラテジーに対する承認は省略され、そのストラテジーに基づいて生成される OpenShift Container Platform のデフォルト値はありません。したがって、生成されるコンテナーの ID と SELinux ラベルは、OpenShift Container Platform ポリシーではなく、コンテナーのデフォルトに基づいて割り当てられます。

以下に RunAsAny の簡単な概要を示します。

  • Pod 定義 (またはイメージ) に定義されるすべての ID が許可されます。
  • Pod 定義 (およびイメージ) に ID がない場合は、コンテナーによって ID が割り当てられます。 Docker の場合、この ID は root (0) です。
  • SELinux ラベルは定義されないため、Docker によって一意のラベルが割り当てられます。

このような理由により、ID 関連のストラテジーについて RunAsAny が設定された SCC は、通常の開発者がアクセスできないように保護する必要があります。一方、MustRunAs または MustRunAsRange に設定された SCC ストラテジーは、(ID 関連のストラテジーについての) ID 検証をトリガーします。 その結果、Pod 定義またはイメージに値が直接指定されていない場合は、OpenShift Container Platform によってデフォルト値がコンテナーに割り当てられます。

注意

RunAsAny FSGroup ストラテジーが設定された SCC へのアクセスを許可すると、ユーザーがブロックデバイスにアクセスするのを防止することもできます。Pod では、ユーザーのブロックデバイスを引き継ぐために fsGroup を指定する必要があります。通常、これを行うには、SCC FSGroup ストラテジーを MustRunAs に設定します。ユーザーの Pod に RunAsAny FSGroup ストラテジーが設定された SCC が割り当てられている場合、ユーザーが fsGroup ストラテジーを各自で指定する必要があることに気づくまで、permission denied エラーが出される可能性があります。

SCC では、許可される ID (ユーザーまたはグループ) の範囲を定義できます。範囲チェックが必要な場合 (MustRunAs を使用する場合など) で、許容可能な範囲が SCC で定義されていない場合は、プロジェクトによって ID 範囲が決定されます。したがって、プロジェクトでは、許容可能な ID の範囲がサポートされます。ただし、SCC とは異なり、プロジェクトは runAsUser などのストラテジーを定義しません。

許容可能な範囲を設定すると、コンテナー ID の境界を定義するだけでなく、範囲の最小値を対象の ID のデフォルト値にできるので役に立ちます。たとえば、SCC ID ストラテジーの値が MustRunAs で、ID 範囲の最小値が 100で、ID が Pod 定義に存在しない場合、100 がこの ID のデフォルト値になります。

Pod の受付プロセスの一環として、Pod で使用可能な SCC が (ほとんどの場合は優先順位の高い SCC から最も制限の厳しい SCC の順序で) 検査され、Pod の要求に最も一致する SCC が選択されます。SCC のストラテジータイプを RunAsAny に設定すると、制限が緩和されます。一方、MustRunAs タイプに設定すると、制限がより厳しくなります。これらすべてのストラテジーが評価されます。Pod に割り当てられた SCC を確認するには、oc get pod コマンドを使用します。

# oc get pod <pod_name> -o yaml
...
metadata:
  annotations:
    openshift.io/scc: nfs-scc 1
  name: nfs-pod1 2
  namespace: default 3
...
1
Pod が使用した SCC (この場合は、カスタム SCC) の名前。
2
Pod の名前。
3
プロジェクトの名前。OpenShift Container Platform では、namespace とプロジェクトは置き換え可能な用語として使用されています。詳細は、Projects and Users を参照してください。

Pod で一致した SCC をすぐに確認できない場合があります。 そのため、上記のコマンドは、ライブコンテナーの UID、補助グループ、および SELinux のラベル変更を理解するのに非常に役立ちます。

ストラテジーが RunAsAny に設定された SCC では、そのストラテジーの特定の値を Pod 定義 (またはイメージ) に定義できます。これがユーザー ID (runAsUser) に適用される場合、コンテナーが root として実行されないように SCC へのアクセスを制限することが推奨されます。

Pod が 制限付き SCC に一致することが多くあるため、これに伴うセキュリティーについて理解しておくことが重要です。制限付き SCC には以下の特性があります。

  • runAsUser ストラテジーが MustRunAsRange に設定されているため、ユーザー ID が制限されます。これにより、ユーザー ID の検証が強制的に実行されます。
  • 許可できるユーザー ID の範囲が SCC で定義されないため (詳細については、oc get -o yaml --export scc restricted を参照してください)、プロジェクトの openshift.io/sa.scc.uid-range 範囲が範囲のチェックとデフォルト ID に使用されます (必要な場合)。
  • デフォルトのユーザー ID は、ユーザー ID が Pod 定義で指定されておらず、一致する SCC の runAsUserMustRunAsRange に設定されている場合に生成されます。
  • SELinux ラベルが必要です (seLinuxContextMustRunAs に設定されているため)。 プロジェクトのデフォルトの MCS ラベルが使用されます。
  • FSGroup ストラテジーが MustRunAs に設定され、指定される最初の範囲の最小値を値に使用するように指示されているため、fsGroup ID が単一の値に制限されます。
  • 許容可能な fsGroup ID の範囲が SCC で定義されないため、プロジェクトの openshift.io/sa.scc.supplemental-groups の範囲 (またはユーザー ID に使用されるものと同じ範囲) の最小値が検証とデフォルト ID に使用されます (必要な場合)。
  • デフォルトの fsGroup ID は、fsGroup ID が Pod で指定されておらず、一致する SCC の FSGroupMustRunAs に設定されている場合に生成されます。
  • 範囲チェックが必要でないため、任意の補助グループ ID が許可されます。これは supplementalGroups ストラテジーが RunAsAny に設定されているためです。
  • 実行中の Pod に対してデフォルトの補助グループは生成されません。上記の 2 つのストラテジーについて RunAsAny が設定されているためです。したがって、グループが Pod 定義 (またはイメージ) に定義されていない場合は、コンテナーには補助グループが事前に定義されません。

以下に、SCC とプロジェクトの相互関係をまとめた default プロジェクトとカスタム SCC (my-custom-scc) の例を示します。

$ oc get project default -o yaml 1
...
metadata:
  annotations: 2
    openshift.io/sa.scc.mcs: s0:c1,c0 3
    openshift.io/sa.scc.supplemental-groups: 1000000000/10000 4
    openshift.io/sa.scc.uid-range: 1000000000/10000 5

$ oc get scc my-custom-scc -o yaml
...
fsGroup:
  type: MustRunAs 6
  ranges:
  - min: 5000
    max: 6000
runAsUser:
  type: MustRunAsRange 7
  uidRangeMin: 1000100000
  uidRangeMax: 1000100999
seLinuxContext: 8
  type: MustRunAs
  SELinuxOptions: 9
    user: <selinux-user-name>
    role: ...
    type: ...
    level: ...
supplementalGroups:
  type: MustRunAs 10
  ranges:
  - min: 5000
    max: 6000
1
default はプロジェクトの名前です。
2
デフォルト値は、対応する SCC 戦略が RunAsAny でない場合にのみ生成されます。
3
Pod 定義または SCC で定義されていない場合の SELinux のデフォルト値です。
4
許容可能なグループ ID の範囲です。ID の検証は、SCC ストラテジーが RunAsAny の場合にのみ実行されます。複数の範囲をコンマで区切って指定できます。サポートされている形式についてはこちら を参照してください。
5
<4> と同じですが、ユーザー ID に使用されます。また、ユーザー ID の単一の範囲のみがサポートされます。
6 10
MustRunAs は、グループ ID の範囲チェックを実施して、コンテナーのグループのデフォルトを指定します。この SCC の定義に基づく場合、デフォルトは 5000 になります (最小の ID 値)。範囲が SCC から省略される場合、デフォルトは 1000000000 になります (プロジェクトから派生します)。サポートされている別のタイプ RunAsAny では、範囲チェックを実行しないため、いずれのグループ ID も許可され、デフォルトグループは生成されません。
7
MustRunAsRange は、ユーザー ID の範囲チェックを実施して、UID のデフォルトを指定します。この SCC の定義に基づく場合、デフォルトの UID は 1000100000 になります (最小値)。最小範囲と最大範囲が SCC から省略される場合、デフォルトのユーザー ID は 1000000000 になります (プロジェクトから派生します)。これ以外には MustRunAsNonRootRunAsAny のタイプがサポートされます。許可される ID の範囲は、ターゲットのストレージに必要ないずれのユーザー ID も含めるように定義することができます。
8
MustRunAs に設定した場合は、コンテナーは SCC の SELinux オプション、またはプロジェクトに定義される MCS のデフォルトを使用して作成されます。RunAsAny というタイプは、SELinux コンテキストが不要であることや、Pod に定義されていない場合はコンテナーに設定されないことを示します。
9
SELinux のユーザー名、ロール名、タイプ、およびラベルは、ここで定義できます。

2 つの形式が許可される範囲にサポートされています。

  1. M/NM は開始 ID で N はカウントです。 したがって、範囲は M から M+N-1 (これ自体を含む) までになります。
  2. M-NM は同じく開始 ID で N は終了 ID です。デフォルトのグループ ID が最初の範囲の開始 ID になります (このプロジェクトでは 1000000000 desu )。SCC で最小のグループ ID が定義されていない場合は、プロジェクトのデフォルトの ID が適用されます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.