27.18.3. 補助グループ
補助グループの操作にあたっては、事前に SCC、デフォルト、許可される範囲 の説明をお読みください。
補助グループは 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 の検証が必要になることがあります (supplementalGroups を MustRunAs に設定した結果など)。ただし、制限付き SCC の場合はこれと異なります。プロジェクトがこの NFS エクスポートにアクセスするようにカスタマイズされていない限り、通常プロジェクトが 5555 というグループ ID を許可することはありません。したがって、このシナリオでは、前述の Pod の 5555 というグループ ID は SCC またはプロジェクトの許可されたグループ ID の範囲内にないために Pod は失敗します。
補助グループとカスタム SCC
前述の例 にあるような状況に対応するため、以下のようカスタム SCC を作成することができます。
- 最小と最大のグループ ID を定義する。
- ID の範囲チェックを実施する。
- グループ ID 5555 を許可する。
多くの場合、定義済みの SCC を修正したり、定義済みプロジェクトで許可される ID の範囲を変更したりするよりも、新規の SCC を作成する方が適切です。
新規 SCC を作成するには、既存の SCC をエクスポートし、新規の SCC の要件を満たすように YAML ファイルをカスタマイズするのが最も簡単な方法です。以下に例を示します。
制限付き SCC を新規 SCC のテンプレートとして使用します。
$ oc get -o yaml --export scc restricted > new-scc.yaml
- 必要な仕様に合うように new-scc.yaml ファイルを編集します。
新規 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 によって許可されるようになったためです。
