27.18.4. fsGroup

fsGroup は Pod のファイルシステムグループの ID を定義するもので、コンテナーの補助グループに追加されます。supplementalGroups の ID は共有ストレージに適用されますが、fsGroup の ID はブロックストレージに使用されます。

ブロックストレージ (Ceph RBD、iSCSI、各種クラウドストレージなど) は通常、ブロックストレージボリュームを直接に、または PVC を使用して要求した単一 Pod に専用のものとして設定されます。共有ストレージとは異なり、ブロックストレージは Pod によって引き継がれます。つまり、Pod 定義 (またはイメージ) で指定されたユーザー ID とグループ ID が実際の物理ブロックデバイスに適用されます。 通常、ブロックストレージは共有されません。

以下の fsGroup の定義は Pod 定義の一部分です。

kind: Pod
...
spec:
  containers:
  - name: ...
  securityContext: 1
    fsGroup: 5555 2
  ...

supplementalGroups と同様に、前述の Pod にあるすべてのコンテナー (一致する SCC またはプロジェクトでグループ 5555 を許可することを前提とします) は、グループ 5555 のメンバーとなり、コンテナーのユーザー ID に関係なくブロックボリュームにアクセスできます。Pod が制限付き SCC に一致し、その fsGroup ストラテジーが MustRunAs である場合、Pod の実行は失敗します。しかし、SCC の fsGroup ストラテジーを RunAsAny に設定した場合は、任意の fsGroup ID (5555 を含む) が許可されます。SCC の fsGroup ストラテジーを RunAsAny に設定して、fsGroup ID を指定しない場合は、ブロックストレージの引き継ぎは行われず、Pod へのパーミッションが拒否される可能性があります。

fsGroups とカスタム SCC

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

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

以下の新規 SCC の定義の一部について見てみましょう。

# oc get -o yaml --export scc new-scc
...
kind: SecurityContextConstraints
...
fsGroup:
  type: MustRunAs 1
  ranges: 2
  - max: 6000
    min: 5000 3
...

前述の Pod をこの新規 SCC に対して実行すると (当然ですが Pod が新しい SCC に一致することを前提とします)、Pod が開始されます。これは、Pod 定義で指定したグループ 5555 がカスタム SCC によって許可されているためです。また、Pod でブロックデバイスの引き継ぎが行われます。 そのため、ブロックストレージを Pod の外部のプロセスから表示する場合、そのグループ ID は実際には 5555 になります。

以下は、ブロックの所有権をサポートしているボリュームの例です。