27.2.4. NFS 볼륨 보안
이 섹션에서는 일치하는 권한 및 SELinux 고려 사항을 포함하여 NFS 볼륨 보안에 대해 설명합니다. 사용자는 POSIX 권한, 프로세스 UID, 추가 그룹 및 SELinux의 기본 사항을 이해하고 있어야 합니다.
NFS 볼륨을 구현하기 전에 전체 볼륨 보안 주제를 참조하십시오.
개발자는 포드 정의의 볼륨 섹션에서 이름으로 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 소유자)의 UID 또는 디렉터리에 액세스하려면 보조 그룹에서 5555 와 함께 실행해야 합니다.
65534의 소유자 ID가 예제로 사용됩니다. NFS의 root_squash는 루트 (0) 를 nfsnobody (5534)에 매핑하지만 NFS 내보내기에는 임의의 소유자 ID가 있을 수 있습니다. NFS 내보내기에는 소유자 65534가 필요하지 않습니다.
27.2.4.1. 그룹 ID
NFS 액세스를 처리하는 권장 방법(NFS 내보내기에 대한 권한을 변경하는 옵션이 아님 가정)은 보조 그룹을 사용하는 것입니다. OpenShift Container Platform의 추가 그룹은 공유 스토리지에 사용되며 NFS가 그 예입니다. 반대로 Ceph RBD 또는 iSCSI와 같은 블록 스토리지는 포드의 securityContext 에 있는 fsGroup SCC 전략과 fsGroup 값을 사용합니다.
일반적으로 사용자 ID를 사용하는 대신 추가 그룹 ID를 사용하여 영구 스토리지에 액세스하는 것이 좋습니다. 보충 그룹은 전체 볼륨 보안 주제에서 자세히 다룹니다.
위에 표시된 대상 NFS 디렉터리 의 그룹 ID는 5555이므로 Pod는 Pod 수준 securityContext 정의에서 supplementalGroups 를 사용하여 해당 그룹 ID를 정의할 수 있습니다. 예를 들면 다음과 같습니다.
spec:
containers:
- name:
...
securityContext: 1
supplementalGroups: [5555] 2
Pod의 요구 사항을 충족할 수 있는 사용자 지정 SCC가 없는 경우 Pod는 restricted SCC와 일치할 수 있습니다. 이 SCC에는 supplementalGroups 전략이 RunAsAny 로 설정되어 있습니다. 즉, 범위를 확인하지 않고 제공된 그룹 ID가 허용됩니다.
그 결과 위의 Pod에서 승인이 전달 및 실행됩니다. 그러나 그룹 ID 범위 확인이 필요한 경우 Pod 보안 및 사용자 지정 SCC에 설명된 대로 사용자 지정 SCC 가 권장되는 솔루션입니다. 최소 및 최대 그룹 ID가 정의되고, 그룹 ID 범위 검사가 적용되며, 5555 그룹 ID가 허용되도록 사용자 지정 SCC를 생성할 수 있습니다.
사용자 정의 SCC를 사용하려면 먼저 적절한 서비스 계정에 추가해야 합니다. 예를 들어 Pod 사양에 다른 값이 지정된 경우를 제외하고 지정된 프로젝트에서 기본 서비스 계정을 사용합니다. 자세한 내용은 사용자, 그룹 또는 프로젝트에 SCC 추가를 참조하십시오.
