소개
보고서 애플리케이션의 설정은 이미 읽기 전용이지만 아직 root로 실행됩니다. 유지보수 담당자로서 실제 문서 생성을 유지하며 준비된 애플리케이션 사용자를 선택합니다.
이 독립 환경에는 자체 보고서 컨테이너와 데이터가 있습니다. UID와 출력 소유권을 확인하고 앞서 연습한 실행 형식을 편집한 뒤 서비스를 다시 생성하고 테스트합니다. 먼저 마운트된 설정 보호 실습을 완료하세요.
애플리케이션 사용자 알아보기
이 단계에서는 정상 서비스 동작을 확인하고 유지보수 사용자와 컨테이너 프로세스 사용자를 구분합니다. 새 환경은 설정 마운트가 이미 읽기 전용이지만 생성기는 아직 root로 실행됩니다.
/home/labex/project/report-desk에서 시작하는 Maintenance를 사용합니다. 준비된 report-renderer 컨테이너만 관리하는 터미널입니다. 필요하면 cd /home/labex/project/report-desk로 돌아갑니다. sudo docker exec는 Docker에 대상 내부 명령 실행을 요청합니다. id는 숫자 사용자 ID(UID)와 그룹 ID(GID)를 표시합니다.
sudo docker exec report-renderer id
uid=0(root) gid=0(root) groups=0(root)
컨테이너의 UID 0은 root입니다. 접근 가능한 파일에 대해 보고서 애플리케이션에 필요한 것보다 많은 권한을 가집니다. 컨테이너 root는 별도 VM의 관리자가 아니며 컨테이너는 호스트 커널을 공유합니다. 이 실습은 파일 접근을 줄이며 모든 컨테이너 위험을 해결하지는 않습니다.
준비된 애플리케이션 사용자는 UID/GID 1200:1200입니다. 숫자 ID는 이미지에 이름 있는 계정을 추가하지 않아도 작동합니다. 호스트 디렉터리 소유자는 해당 사용자의 쓰기를 허용해야 합니다. ls -ldn은 디렉터리 자체(-d), 자세한 권한(-l), 숫자 ID(-n)를 표시합니다.
ls -ldn output
drwxr-xr-x와 소유자/그룹 1200 1200을 찾습니다. 소유자는 rwx, 즉 읽기, 쓰기, 디렉터리 통과 권한이 있습니다. 다른 사용자는 r-x로 읽고 통과할 수 있지만 쓸 수 없습니다. 환경은 의도한 사용자를 위해 이 디렉터리를 준비했습니다.
이미 연습한 POST 요청으로 기준 문서를 생성합니다. curl -fsS는 HTTP 오류를 보고하며 -X POST는 업무 작업을 요청합니다.
curl -fsS -X POST http://localhost:8090/render/baseline
{"saved": "/output/baseline.json", "total": 37, "uid": 0}
보고서는 작동하지만 여전히 UID 0이 생성했습니다. Document Desk를 열어 저장된 문서를 봅니다. 이 페이지는 실제 출력 파일을 나열합니다.
준비된 사용자 선택
이 단계에서는 필요한 파일 시스템 접근을 유지하면서 실행 선언의 애플리케이션 사용자를 바꿉니다. cat으로 스크립트를 표시합니다.
cat launch.sh
sudo는 호스트 관리 작업을 허용합니다. 별도로 --user가 컨테이너 애플리케이션의 사용자와 그룹을 결정합니다. 0:0은 UID 0과 GID 0을 뜻하며 1200:1200으로 바꾸면 준비된 사용자를 선택합니다. 포트 8090, 이미지, 두 마운트 경로를 유지합니다. 설정 줄에는 이미 dst=/config,readonly가 있으며 출력 줄은 쓰기 가능해야 합니다.
터미널 편집기를 엽니다.
nano launch.sh
방향키로 --user 0:0만 --user 1200:1200으로 바꿉니다. Ctrl+O, Enter로 저장하고 Ctrl+X로 종료합니다. 파일을 다시 표시합니다.
cat launch.sh
사용자 줄은 다음과 같아야 합니다.
--user 1200:1200 \
선언만 바꾸어서는 실행 중인 프로세스가 갱신되지 않습니다. 다시 생성하기 전에 출력 디렉터리의 의도한 소유권을 명시합니다. chown은 숫자 소유자와 그룹을 설정합니다. 호스트 유지보수 사용자와 ID가 달라 sudo가 필요합니다. 디렉터리만 변경하며 기존 파일 전체를 변경하지는 않습니다.
sudo chown 1200:1200 output
모두 읽기 전용으로 만들지 마세요. 문서 생성에는 출력 쓰기가 필요합니다. 소유권 문제를 피하려고 모든 사용자에게 쓰기를 허용하지도 마세요. 기존 디렉터리 권한 755로 준비된 소유자가 쓸 수 있습니다.
다시 생성하고 업무 결과 유지
이 단계에서는 새 사용자를 적용하고 정상 출력과 보호된 입력 경계를 테스트합니다. 앞서처럼 대상 컨테이너만 제거하고 대체 컨테이너를 시작합니다.
sudo docker rm -f report-renderer
bash launch.sh
시작에 실패하면 nano로 launch.sh를 수정하고 같은 제거 명령으로 실패한 대상을 제거한 뒤 스크립트를 다시 실행합니다. 호스트 데이터는 남습니다. 실행 중인 사용자를 확인합니다.
sudo docker exec report-renderer id
uid=1200 gid=1200 groups=1200
시작할 때까지 잠시 기다린 다음 최종 문서를 생성합니다.
curl -fsS -X POST http://localhost:8090/render/final
{"saved": "/output/final.json", "total": 37, "uid": 1200}
Permission denied는 보통 출력 디렉터리 소유자가 잘못되었거나 이전 root 실행이 final.json을 만들었음을 뜻합니다. 배운 명령 sudo chown 1200:1200 output으로 디렉터리를 고칩니다. 이전 최종 파일이 있으면 sudo rm output/final.json으로 해당 생성 문서만 지우고 다시 요청합니다. /output의 Read-only file system은 출력 마운트를 실수로 제한했음을 뜻합니다. 선언을 고치고 컨테이너를 다시 생성합니다.
생성된 파일을 확인합니다. ls -ln은 숫자 파일 소유권을, cat은 내용을 보여 줍니다.
ls -ln output/final.json
cat output/final.json
소유자 1200, "uid": 1200, 합계 37, Report for Harbor Books: 37 orders를 찾습니다. Document Desk를 새로 고쳐 파일을 봅니다. 마지막으로 설정 보호가 유지되는지 확인합니다.
sudo docker exec report-renderer touch /config/probe.txt
touch: /config/probe.txt: Read-only file system
이 실패는 예상된 결과입니다. 비 root 사용자와 읽기 전용 마운트는 서로 다른 문제를 해결합니다. UID 선택은 프로세스 권한을 줄이며 마운트 모드는 컨테이너 root의 설정 쓰기도 막습니다. 생성기는 여전히 실제 업무를 수행합니다.
요약
호스트 유지보수 접근과 애플리케이션 사용자를 구분하고 UID/GID 1200을 선택하면서 출력 디렉터리를 유지했습니다. 실행 중인 프로세스와 새 문서는 이제 UID 1200을 사용하며 설정 쓰기는 계속 거부됩니다.
