27.18.5. ユーザー ID


注記

補助グループの操作にあたっては、事前に SCC、デフォルト、許可される範囲 の説明をお読みください。

ヒント

永続ストレージへのアクセスを取得する場合、通常はグループ ID (補助 グループまたは fsGroup) を使用する方がユーザー ID を使用するよりも適切です。

ユーザー ID は、コンテナーイメージまたは Pod 定義で定義できます。Pod 定義では、1 つのユーザー ID をすべてのコンテナーに対してグローバルに定義するか、個々のコンテナーに固有のものとして定義するか、またはその両方として定義できます。以下の Pod 定義の一部ではユーザー ID を指定しています。

spec:
  containers:
  - name: ...
    securityContext:
      runAsUser: 1000100001

1000100001 はコンテナー固有の ID であり、エクスポートの所有者 ID と一致します。NFS エクスポートの所有者 ID が 54321 である場合は、その番号が Pod 定義で使用されます。コンテナー定義の外部で securityContext を指定すると、ID は Pod 内のすべてのコンテナーに対してグローバルになります。

グループ ID と同じように、SCC やプロジェクトで設定されているポリシーに従ってユーザー ID を検証することもできます。SCC の runAsUser ストラテジーを RunAsAny に設定した場合は、Pod 定義またはイメージで定義されているすべてのユーザー ID が許可されます。

警告

つまり、0 (root) の UID さえも許可されることになります。

代わりに runAsUser ストラテジーを MustRunAsRange に設定した場合は、指定したユーザー ID について、許可される ID の範囲にあるかどうかが検証されます。Pod でユーザー ID を指定しない場合は、デフォルト ID が許可されるユーザー ID の範囲の最小値に設定されます。

先の NFS の例 に戻って、コンテナーでその UID を 1000100001 に設定する必要があります (上記の Pod の例を参照してください)。デフォルトプロジェクトと制限付き SCC を想定した場合、Pod で要求した 1000100001 というユーザー ID は許可されず、したがって Pod は失敗します。Pod が失敗するのは以下の理由によります。

  • Pod が独自のユーザー ID として 1000100001 を要求している。
  • 使用可能なすべての SCC が独自の runAsUser ストラテジーとして MustRunAsRange を使用しており、そのため UID の範囲チェックが要求される。
  • 1000100001 が SCC にもプロジェクトのユーザー ID 範囲にも含まれていない。

この状況に対応するには、適切なユーザー ID 範囲を指定して新規 SCC を作成します。また、新規プロジェクトを適切なユーザー ID 範囲を定義して作成することもできます。さらに、以下のような推奨されない他のオプションがあります。

  • 最小および最大のユーザー ID 範囲に 1000100001 を組み込むように 制限付き SCC を変更できます。ただし、これは定義済みの SCC の変更をできる限り避ける必要があるため推奨されません。
  • RunAsAnyrunAsUser の値に使用できるように 制限付き SCC を変更できます。これにより、ID 範囲のチェックを省略できます。この方法ではコンテナーが root として実行される可能性があるため、この方法を使用しないことを強く推奨します。
  • ユーザー ID 1000100001 を許可するように デフォルトプロジェクトの UID 範囲を変更できます。通常、この方法も推奨できません。 ユーザー ID に単一範囲しか指定できず、範囲が変更された場合に他の Pod が実行されなくなる可能性があるためです。

ユーザー ID とカスタム SCC

定義済みの SCC を変更することは可能な限り避ける必要があります。組織のセキュリティー上のニーズに合ったカスタム SCC を作成するか、または必要なユーザー ID をサポートする 新規プロジェクトを作成する ことを推奨します。

前述の例にあるような状況に対応するため、以下のようにカスタム SCC を作成することができます。

  • 最小と最大のユーザー ID を定義する。
  • UID の範囲チェックを引き続き実施する。
  • 1000100001 という UID を許可する。

以下に例を示します。

$ oc get -o yaml --export scc nfs-scc

allowHostDirVolumePlugin: false 1
...
kind: SecurityContextConstraints
metadata:
  ...
  name: nfs-scc 2
priority: 9 3
requiredDropCapabilities: null
runAsUser:
  type: MustRunAsRange 4
  uidRangeMax: 1000100001 5
  uidRangeMin: 1000100001
...
1
allowXX のブール値は制限付き SCC の場合と同じです。
2
この新規 SCC の名前は nfs-scc です。
3
数値が大きいほど優先順位が高くなります。Nil の場合や省略した場合は優先順位が最も低くなります。優先順位が高い SCC は優先順位が低い SCC より前に並べ替えられるため、新規 Pod と一致する確率が高くなります。
4
runAsUser ストラテジーは MustRunAsRange に設定されています。 つまり、UID の範囲チェックが実施されます。
5
UID の範囲は 1000100001 ~ 1000100001 です (1 つの値の範囲)。

これで、先の例の Pod 定義に runAsUser: 1000100001 が表示され、Pod が新規の nfs-scc と一致し、UID 1000100001 で実行できるようになります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.