测验：任意 UID 与 SCC

OpenShift 의 이미지 작성 지침이 임의 UID 에서도 동작하게 하려고 권하는 방법은?

• 쓰는 디렉터리를 UID 1001 소유로 chown 하고 USER 1001 로 둔다
• 이미지 안 /etc/passwd 를 누구나 쓸 수 있게 열어 둔다
• 쓰는 경로를 root 그룹 소유로 두고 그룹 권한을 소유자와 같게 맞춘다
• 시작 스크립트가 sudo 로 권한을 올려 디렉터리를 만든다

프로젝트 주석이 openshift.io/sa.scc.uid-range=1000680000/10000 일 때 restricted-v2 로 들어온 파드가 runAsUser 를 적지 않았다면 어떤 UID 로 도는가?

• 1000680000
• 이미지의 USER 에 적힌 값
• 1000689999
• 범위 안에서 파드마다 무작위로 고른 값

레거시 이미지가 루트 소유 /app/data 에 쓰다 죽는다. 파드에 fsGroup 을 이미 주었는데도 실패한 이유는?

• fsGroup 은 runAsGroup 0 과 함께 쓰면 무시되기 때문이다
• fsGroup 은 볼륨의 그룹 소유를 바꿀 뿐 이미지 파일시스템은 바꾸지 않는다
• restricted 기준이 fsGroup 필드를 조용히 지우기 때문이다
• fsGroup 은 컨테이너가 한 번 재시작된 뒤에야 적용된다

임의 UID 문제를 우회하려고 runAsUser 0 인 initContainer 로 chown 하는 파드를 restricted 네임스페이스에 넣었다. 결과는?

• initContainer 만 root 로 돌고 앱 컨테이너는 임의 UID 로 뜬다
• chown 은 되지만 앱이 뜬 뒤 소유권이 원래대로 돌아간다
• 파드는 만들어지고 initContainer 가 권한 오류로 반복 재시작된다
• 어드미션이 runAsUser=0 을 이유로 파드 생성 자체를 거절한다

k3s 에서 임의 UID 로 돌린 컨테이너의 whoami 가 unknown uid 로 실패했다. 이것을 OpenShift 로 옮겨 생각할 때 맞는 해석은?

• 문서상 CRI-O 가 passwd 항목을 넣어 줄 수 있어 그대로 옮기면 안 된다
• OpenShift 에서도 똑같이 실패하므로 이미지마다 nss 도구가 필요하다
• whoami 실패는 seccomp RuntimeDefault 가 getpwuid 호출을 막았기 때문이다
• k3s 가 SCC 를 몰라 UID 를 잘못 넣었기 때문이며 주석을 고치면 해결된다

OCP 판에 따른 기본 SCC 에 대해 문서에서 확인한 사실로 맞는 것은?

• 4.19 부터 anyuid 가 인증된 사용자의 기본 SCC 가 됐다
• 4.20·4.21 문서에 restricted-v3 가 새 설치의 기본으로 추가됐다
• restricted-v2 는 4.21 에서 제거되어 더 이상 쓸 수 없다
• 모든 판에서 기본 SCC 는 privileged 이고 PSA 가 대신 막는다