🛡️ Docker Swarm에서 --with-registry-auth의 늪 탈출하기: 보안과 효율성 사이의 균형

안녕하세요! 오늘은 도커 스웜 모드를 운영하면서 가장 많이 질문받는 내용 중 하나인 프라이빗 레지스트리 인증과 컨테이너 보안 네트워크에 대해 상세히 파헤쳐 보겠습니다. 설계 철학을 바탕으로, 단순한 명령어 설명을 넘어 '왜 이렇게 설계되었는가'에 대한 통찰을 공유해 드립니다. 👨‍🏫

---

1. --with-registry-auth, 넌 대체 정체가 뭐니? 🤔

도커 스웜에서 프라이빗 레지스트리(예: AWS ECR, Azure ACR, Self-hosted Harbor 등)의 이미지를 사용하려면 매니저 노드에서 docker login을 수행합니다. 하지만 정작 배포를 하면 워커 노드들이 이미지를 가져오지 못해 No such image나 Access Denied 에러를 뿜어내곤 하죠.

이때 구원 투수처럼 등장하는 옵션이 바로 --with-registry-auth입니다.

⚙️ 동작 원리: 인증 토큰의 여정

1. 매니저 노드: docker login을 통해 얻은 인증 토큰을 ~/.docker/config.json에 보관합니다.
2. 명령 실행: 사용자가 --with-registry-auth 옵션과 함께 stack deploy 명령을 내립니다.
3. 토큰 전달: 매니저 노드는 자신의 인증 정보를 스웜 API를 통해 해당 서비스를 실행할 모든 워커 노드에게 일시적으로 전달합니다.
4. 이미지 풀(Pull): 워커 노드는 전달받은 따끈따끈한 토큰을 들고 레지스트리에 접근하여 이미지를 내려받습니다.

💡 핵심 포인트:
이 인증 정보는 워커 노드에 영구 저장되지 않습니다.
보안을 위해 배포 시점에만 '반짝' 전달되는 휘발성 데이터입니다.

---

2. "매번 치기 귀찮은데, 자동화는 안 되나요?" 😫

결론부터 말씀드리면, 도커의 공식 설계상 이 옵션을 전역적으로(Default) 활성화하는 방법은 없습니다. 보안 전문가의 시각에서 보면 이는 매우 타당한 설계입니다.

🔒 보안 설계 철학: 명시적 제어

만약 이 옵션이 기본값이라면, 어떤 서비스든 배포될 때마다 매니저의 민감한 인증 토큰이 네트워크를 타고 모든 노드로 뿌려지게 됩니다. 이는 최소 권한 원칙(Principle of Least Privilege)에 위배됩니다. 특정 배포가 인증이 필요한지 아닌지를 운영자가 명시적으로 결정하게 함으로써 보안 사고를 예방하는 것이죠.

🛠️ 현실적인 해결책 (Tip)

매번 입력하는 스트레스에서 벗어나고 싶다면 Shell Alias를 적극 활용하세요.

Bash

# .bashrc 또는 .zshrc에 등록
alias dsd='docker stack deploy --with-registry-auth'
alias dsu='docker service update --with-registry-auth'

 

이제 dsd -c docker-compose.yml web 한 줄이면 모든 인증 문제가 해결됩니다.

---

3. 내부망 보안의 핵심: expose vs ports 🌐

스웜 환경에서 서비스를 구성할 때, 외부 노출이 필요 없는 DB나 내부 API 서버는 어떻게 설정하시나요? 여기서 expose의 진가가 드러납니다.

구분	ports (Port Forwarding)	expose (Internal Only)
접근성	외부 인터넷/호스트에서 접근 가능	동일 Docker 네트워크 내에서만 접근 가능
보안	문을 활짝 열어둔 상태 (위험 노출)	필요한 내부 협업자에게만 문을 열어줌
용도	웹 서버(Nginx), 외부 API 엔드포인트	Database, Redis, Internal Microservices

 

보안 강화를 위해 "외부 진입점(Gateway)만 ports를 열고, 나머지는 모두 expose로 격리"하는 설계를 권장합니다.

---

4. 실전 트러블슈팅: OpenSearch 보안 초기화 오류와 디스크 풀(Full) 🚨

최근 OpenSearch를 Docker Compose로 띄우다 보면 다음과 같은 메시지를 보게 될 때가 있습니다.

opensearch security not initialized

 

이 오류는 보안 플러그인은 켜져 있는데, 설정을 담을 .security 인덱스가 생성되지 않았을 때 발생합니다. 환경 변수(OPENSEARCH_INITIAL_ADMIN_PASSWORD)를 잘 넣었는데도 안 된다면? 범인은 바로 디스크 용량(Disk Full)일 확률이 높습니다.

📉 디스크 용량과 OpenSearch의 관계

OpenSearch(Elasticsearch 계열)는 디스크 사용량이 95%를 넘어가면 데이터 보호를 위해 모든 인덱스를 Read-only 모드로 잠가버립니다.

1. 문제 발생: 디스크가 꽉 차서 .security 인덱스 생성 실패.
2. 로그 확인: docker compose logs에서 No space left on device 또는 Disk watermark exceeded 확인.
3. 해결 방법:
   • docker system prune -a로 불필요한 이미지/볼륨 정리.
   • docker-compose down -v로 꼬여버린 볼륨을 완전히 날리고 재시작.
   • 충분한 여유 공간(최소 10GB 이상 권장) 확보 후 재배포.

---

5. 마치며: 더 나은 데브옵스 환경을 위해 🏗️

도커 스웜은 쿠버네티스에 비해 가볍고 강력한 도구입니다. 하지만 --with-registry-auth와 같은 옵션의 의미를 정확히 모르면 운영 중 예상치 못한 장애(Image Pull Error)를 겪게 됩니다.

 

오늘 살펴본 내용을 요약하자면 이렇습니다:

• --with-registry-auth는 인증 토큰을 워커 노드에 전달하는 보안 장치다.
• 귀찮음을 해결하려면 Alias(별칭)를 사용하자.
• expose를 통해 서비스 간 최소 보안 경계를 구축하자.
• 인프라의 기본은 리소스 관리(디스크 용량)에서 시작된다.