4.11.3. NFS 볼륨 보안
이 섹션에서는 일치하는 권한 및 SELinux 고려 사항을 포함하여 NFS 볼륨 보안에 대해 설명합니다. 사용자는 POSIX 권한, 프로세스 UID, 추가 그룹 및 SELinux의 기본 사항을 이해하고 있어야 합니다.
개발자는 Pod 정의의 볼륨 섹션에서 직접 PVC 또는 NFS 볼륨 플러그인을 참조하여 NFS 스토리지를 요청합니다.
NFS 서버의 /etc/exports 파일에 액세스할 수 있는 NFS 디렉터리가 있습니다. 대상 NFS 디렉터리에는 POSIX 소유자 및 그룹 ID가 있습니다. OpenShift Container Platform NFS 플러그인은 내보낸 NFS 디렉터리에 있는 동일한 POSIX 소유권 및 권한과 함께 컨테이너의 NFS 디렉터리를 마운트합니다. 그러나 컨테이너는 원하는 동작인 NFS 마운트의 소유자와 동일한 유효 UID로 실행되지 않습니다.
예를 들어, 대상 NFS 디렉터리가 NFS 서버에 다음과 같이 표시되는 경우:
$ ls -lZ /opt/nfs -d
출력 예
drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0 /opt/nfs
$ id nfsnobody
출력 예
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)
그러면 컨테이너가 SELinux 레이블과 일치하고 65534, nfsnobody 소유자 또는 디렉터리에 액세스하려면 추가 그룹의 5555와 함께 실행해야 합니다.
65534의 소유자 ID는 예시와 같이 사용됩니다. NFS의 root_squash는 UID가 0인 루트를 UID가 65534인 nfsnobody로 매핑하지만, NFS 내보내기에는 임의의 소유자 ID가 있을 수 있습니다. NFS를 내보내려면 소유자 65534가 필요하지 않습니다.
4.11.3.1. 그룹 ID
NFS 내보내기 권한 변경 옵션이 아닐 경우 NFS 액세스를 처리하는 권장 방법은 추가 그룹을 사용하는 것입니다. OpenShift Container Platform의 추가 그룹은 공유 스토리지에 사용되며 NFS가 그 예입니다. 반면 iSCSI와 같은 블록 스토리지는 Pod의 securityContext에 있는 fsGroup SCC 전략과 fsGroup 값을 사용합니다.
영구 스토리지에 액세스하려면, 일반적으로 추가 그룹 ID vs 사용자 ID를 사용하는 것이 좋습니다.
예제 대상 NFS 디렉터리의 그룹 ID는 5555 이므로 Pod의 securityContext 정의 아래에 supplementalGroups 를 사용하여 해당 그룹 ID를 정의할 수 있습니다. 예를 들면 다음과 같습니다.
spec:
containers:
- name:
...
securityContext: 1
supplementalGroups: [5555] 2
Pod 요구사항을 충족할 수 있는 사용자 지정 SCC가 없는 경우 Pod는 restricted SCC와 일치할 수 있습니다. 이 SCC에는 supplementalGroups 전략이 RunAsAny로 설정되어 있으므로, 범위를 확인하지 않고 제공되는 그룹 ID가 승인됩니다.
그 결과 위의 Pod에서 승인이 전달 및 실행됩니다. 그러나 그룹 ID 범위 확인이 필요한 경우에는 사용자 지정 SCC를 사용하는 것이 좋습니다. 사용자 지정 SCC를 생성하면 최소 및 최대 그룹 ID가 정의되고, 그룹 ID 범위 확인이 적용되며, 5555 그룹 ID가 허용될 수 있습니다.
사용자 정의 SCC를 사용하려면 먼저 적절한 서비스 계정에 추가해야 합니다. 예를 들어, Pod 사양에 다른 값이 지정된 경우를 제외하고 지정된 프로젝트에서 기본 서비스 계정을 사용하십시오.
