Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

27.18.3. 補助グループ

注記

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

ヒント

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

補助グループは Linux の正規グループです。Linux で実行されるプロセスには、UID、GID、および 1 つ以上の補助グループがあります。これらの属性はコンテナーのメインプロセスで設定されます。supplementalGroups ID は、通常は NFS や GlusterFS などの共有ストレージへのアクセスを制御する場合に使用されます。 一方、fsGroup は Ceph RBD や iSCSI などのブロックストレージへのアクセスを制御する場合に使用されます。

OpenShift Container Platform の共有ストレージプラグインは、マウントの POSIX パーミッションとターゲットストレージのパーミッションが一致するようにボリュームをマウントします。たとえば、ターゲットストレージの所有者 ID が 1234 で、そのグループ ID が 5678 の場合、ホストノードのマウントとコンテナーのマウントはそれらの同じ ID を持ちます。したがって、ボリュームにアクセスするためにはコンテナーのメインプロセスがこれらの ID の一方または両方と一致する必要があります。

たとえば、以下の NFS エクスポートについて見てみましょう。

OpenShift Container Platform ノード側:

注記

showmount では、NFS サーバーの rpcbind および rpc.mount が使用するポートへのアクセスが必要です。

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs  *

NFS サーバー側:

# cat /etc/exports
/opt/nfs *(rw,sync,root_squash)
...

# ls -lZ /opt/nfs -d
drwx------. 1000100001 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs

/opt/nfs/ エクスポートには UID 1000100001 とグループ 5555 でアクセスすることができます。通常、コンテナーは root として実行しないようにする必要があります。そのため、この NFS の例では、UID 1000100001 として実行されないコンテナーやグループ 5555 のメンバーでないコンテナーは、NFS エクスポートにアクセスできません。

多くの場合、Pod と一致する SCC では特定のユーザー ID の指定は許可されません。そのため、Pod へのストレージアクセスを許可する場合には、補助グループを使用する方法はより柔軟な方法として使用できます。 たとえば、前述のエクスポートへの NFS アクセスを許可する場合は、グループ 5555 を Pod 定義に定義できます。

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - name: ...
    volumeMounts:
    - name: nfs 1
      mountPath: /usr/share/... 2
  securityContext: 3
    supplementalGroups: [5555] 4
  volumes:
  - name: nfs 5
    nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs 6
1
ボリュームマウントの名前。volumes セクションの名前と一致する必要があります。
2
コンテナーで表示される NFS エクスポートのパス。
3
Pod のグローバルセキュリティーコンテキスト。Pod 内部のすべてのコンテナーに適用されます。コンテナーではそれぞれ独自の securityContext を定義することもできますが、グループ ID は Pod に対してグローバルであり、個々のコンテナーに対して定義することはできません。
4
補助グループ (ID の配列) は 5555 に設定しています。これで、エクスポートへのグループアクセスが許可されます。
5
ボリュームの名前。volumeMounts セクションの名前と一致する必要があります。
6
NFS サーバー上の実際の NFS エクスポートのパス。

前述の Pod にあるすべてのコンテナー (一致する SCC またはプロジェクトでグループ 5555 を許可することを前提とします) は、グループ 5555 のメンバーとなり、コンテナーのユーザー ID に関係なくボリュームにアクセスできます。ただし、ここでの前提条件に留意してください。場合によっては、SCC が許可されるグループ ID の範囲を定義されておらず、代わりにグループ ID の検証が必要になることがあります (supplementalGroupsMustRunAs に設定した結果など)。ただし、制限付き SCC の場合はこれと異なります。プロジェクトがこの NFS エクスポートにアクセスするようにカスタマイズされていない限り、通常プロジェクトが 5555 というグループ ID を許可することはありません。したがって、このシナリオでは、前述の Pod の 5555 というグループ ID は SCC またはプロジェクトの許可されたグループ ID の範囲内にないために Pod は失敗します。

補助グループとカスタム SCC

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

  • 最小と最大のグループ ID を定義する。
  • ID の範囲チェックを実施する。
  • グループ ID 5555 を許可する。

多くの場合、定義済みの SCC を修正したり、定義済みプロジェクトで許可される ID の範囲を変更したりするよりも、新規の SCC を作成する方が適切です。

新規 SCC を作成するには、既存の SCC をエクスポートし、新規の SCC の要件を満たすように YAML ファイルをカスタマイズするのが最も簡単な方法です。以下に例を示します。

  1. 制限付き SCC を新規 SCC のテンプレートとして使用します。

    $ oc get -o yaml --export scc restricted > new-scc.yaml
  2. 必要な仕様に合うように new-scc.yaml ファイルを編集します。
  3. 新規 SCC を作成します。

    $ oc create -f new-scc.yaml
注記

oc edit scc コマンドを使用して、インスタンス化された SCC を修正することができます。

以下の例は nfs-scc という名前の新規 SCC の一部です。

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

allowHostDirVolumePlugin: false 1
...
kind: SecurityContextConstraints
metadata:
  ...
  name: nfs-scc 2
priority: 9 3
...
supplementalGroups:
  type: MustRunAs 4
  ranges:
  -  min: 5000 5
     max: 6000
...
1
allow ブール値は制限付き SCC の場合と同じです。
2
新規 SCC の名前。
3
数値が大きいほど優先順位が高くなります。Nil の場合や省略した場合は優先順位が最も低くなります。優先順位が高い SCC は優先順位が低い SCC より前に並べ替えられるため、新規 Pod と一致する確率が高くなります。
4
supplementalGroups はストラテジーであり、MustRunAs に設定されています。 つまり、グループ ID のチェックが必要になります。
5
複数の範囲を使用することができます。ここで許可されるグループ ID の範囲は 5000 ~ 5999 で、デフォルトの補助グループは 5000 です。

前述の Pod をこの新規 SCC に対して実行すると (当然ですが Pod が新規 SCC に一致することを前提とします)、Pod が開始されます。 これは、Pod 定義で指定したグループ 5555 がカスタム SCC によって許可されるようになったためです。