27.18.3. 보충 그룹
보조 그룹을 사용하기 전에 SCC, 기본값, 허용된 범위를 읽습니다.
보충 그룹은 일반 Linux 그룹입니다. 프로세스가 Linux에서 실행되면 UID, GID 및 하나 이상의 보조 그룹이 있습니다. 이러한 특성은 컨테이너의 기본 프로세스에 대해 설정할 수 있습니다. 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 내보내기에 액세스할 수 없는 멤버가 아닌 컨테이너는 NFS 내보내기에 액세스할 수 없습니다.
포드와 일치하는 SCC에서는 특정 사용자 ID를 지정할 수 없으므로 보충 그룹을 사용하면 포드에 스토리지 액세스 권한을 부여할 수 있습니다. 예를 들어 위의 내보내기에 대한 NFS 액세스 권한을 부여하려면 Pod 정의에 5555 그룹을 정의할 수 있습니다.
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
- 포드 글로벌 보안 컨텍스트. 포드 내의 모든 컨테이너에 적용됩니다. 각 컨테이너는
securityContext를 정의할 수도 있지만 그룹 ID는 포드에 전역적이며 개별 컨테이너에 대해 정의할 수 없습니다. - 4
- ID 배열인 보조 그룹은 5555로 설정됩니다. 이렇게 하면 그룹에 내보내기에 대한 액세스 권한이 부여됩니다.
- 5
- 볼륨 이름입니다.
volumeMounts섹션의 이름과 일치해야 합니다. - 6
- NFS 서버의 실제 NFS 내보내기 경로입니다.
위의 포드의 모든 컨테이너(일치 SCC 또는 프로젝트를 사용하면 5555그룹이 허용됨)는 5555 그룹의 멤버이며 컨테이너의 사용자 ID와 관계없이 볼륨에 액세스할 수 있습니다. 그러나 위의 가정은 매우 중요합니다. SCC가 허용되는 그룹 ID 범위를 정의하지 않고 그룹 ID 유효성 검사(Supplemental Groups 가 MustRunAs로 설정된 결과)를 대신 지정해야 하는 경우가 있습니다. 이는 restricted SCC의 경우가 아닙니다. 프로젝트가 이 NFS 내보내기에 액세스하도록 사용자 지정되지 않은 한 프로젝트는 5555 의 그룹 ID를 허용하지 않습니다. 따라서 이 시나리오에서는 5555 의 그룹 ID가 SCC의 허용된 그룹 ID 범위 내에 없으므로 위의 Pod가 실패합니다.
보충 그룹 및 사용자 지정 SCC
이전 예제의 상황을 해결하기 위해 다음과 같이 사용자 정의 SCC를 생성할 수 있습니다.
- 최소 및 최대 그룹 ID가 정의됩니다.
- ID 범위 검사가 강제 적용됨
- 5555 의 그룹 ID가 허용됩니다.
사전 정의된 SCC를 수정하거나 사전 정의된 프로젝트에서 허용되는 ID 범위를 변경하는 대신 새 SCC를 생성하는 것이 좋습니다.
새 SCC를 생성하는 가장 쉬운 방법은 기존 SCC를 내보내고 YAML 파일을 사용자 지정하여 새 SCC의 요구 사항을 충족하는 것입니다. 예를 들면 다음과 같습니다.
restricted 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부울은 restricted SCC와 동일합니다.- 2
- 새 SCC의 이름입니다.
- 3
- 숫자로 큰 숫자가 우선 순위가 높습니다. nil 또는 omitted가 가장 낮은 우선 순위입니다. 우선순위가 높은 SCC가 더 낮은 우선 순위 SCC보다 먼저 정렬되므로 새 Pod를 일치시킬 가능성이 더 높습니다.
- 4
supplementalGroups는 전략이며 MustRunAs 로 설정되어 있으므로 그룹 ID 검사가 필요합니다.- 5
- 여러 범위가 지원됩니다. 여기서 허용되는 그룹 ID 범위는 5000 ~ 5999이며 기본 보조 그룹은 5000입니다.
이전에 표시된 동일한 Pod가 이 새 SCC에 대해 실행되는 경우(물론 포드는 새 SCC와 일치), 포드 정의에 제공된 5555 그룹이 이제 사용자 지정 SCC에서 허용되므로 시작됩니다.
