Docker push denied 해결: 이미지 태그와 Docker Hub 권한 확인

Docker Hub에 docker push를 실행했을 때 denied: requested access to the resource is denied가 나타나면 먼저 이미지 이름의 네임스페이스와 로그인 계정의 쓰기 권한을 확인한다. 로그인 성공은 대상 저장소에 쓰기 권한이 있다는 뜻은 아니다.

로컬 이미지가 레지스트리 저장소로 전달되는 과정을 표현한 AI 생성 일러스트

이 글은 Docker Hub 기준이며 2026년 11월 15일 확인한 Docker 공식 이미지 발행 안내를 바탕으로 한다. 명령은 설명용이며 실제 레지스트리에 푸시하지 않았다.

이미지 이름이 목적지를 결정한다

Docker Hub 이미지 이름은 보통 NAMESPACE/REPOSITORY:TAG 형식이다. 네임스페이스는 Docker ID 또는 쓰기 권한이 있는 조직 이름이다. myapp:1.0처럼 네임스페이스를 생략한 채 올리려 하면 의도한 개인 저장소가 아닌 기본 네임스페이스를 향할 수 있다. 태그를 생략하면 기본값은 latest다. 태그는 이미지의 버전처럼 쓸 수 있지만 불변 식별자는 아니다. 이미지 이름과 태그

예를 들어 로컬 이미지가 myapp:1.0이고 Docker ID가 exampleuser라면 다음처럼 대상 이름을 붙인다. 실제 계정과 저장소 이름으로 바꿔야 한다.

docker tag는 기존 이미지에 새 이름을 붙인다. 빌드 결과와 대상 이름이 같은 이미지 ID를 가리키는지 확인한다. 이름과 태그를 잘못 지정하면 로컬 이미지가 없다는 오류가 날 수 있으며 이는 레지스트리의 권한 거부와 구분한다.

Docker Hub에 로그인하고 올리기

docker login은 기본적으로 Docker Hub를 대상으로 한다. 명령의 인증 절차를 따르고 비밀번호나 토큰을 명령행 인자, 로그, 저장소에 남기지 않는다. CI에서는 표준 입력을 이용한 로그인과 해당 CI의 비밀 저장소를 사용한다. 계정·토큰에 대상 저장소 쓰기 권한이 필요한 것은 동일하다.

업로드 성공 후 출력되는 digest와 대상 태그를 기록하고 Docker Hub의 해당 저장소에서 확인한다. 공개 저장소는 다른 환경에서 pull해 확인할 수 있고 비공개 저장소는 읽기 권한이 필요하다. 태그는 이후 다른 이미지로 바뀔 수 있으므로 배포 대상을 고정해야 한다면 digest 사용을 고려한다. 푸시 명령

여전히 거부된다면

• 목적지: 출력된 저장소 이름이 의도한 Docker ID 또는 조직과 정확히 일치하는지 확인한다. 조직 저장소라면 조직의 쓰기 권한을 확인한다.

• 인증 주체: 로그인한 계정과 CI에서 사용한 자격 증명이 같은지, 토큰이 유효하고 쓰기 범위를 갖는지 확인한다. sudo나 다른 OS 사용자로 실행하면 다른 Docker 설정을 사용할 수 있다. 현재 셸과 CI의 실행 사용자를 비교한다.

• 저장소 상태: 이름과 저장소 존재 여부, 조직 정책을 확인한다. 저장소 자동 생성 및 공개 범위는 서비스 설정에 영향을 받으므로 사전에 Docker Hub에서 확인한다.

• 다른 레지스트리: registry.example.com/team/myapp:1.0처럼 호스트가 포함된 이름은 Docker Hub가 아닌 해당 레지스트리를 향한다. 그 호스트에 로그인하고 해당 서비스의 권한·프로젝트 규칙을 확인한다.

Docker의 공식 안내도 이 오류에서 로그인과 이미지 태그의 사용자 이름을 먼저 확인하도록 권한다. 권한 문제를 해결하기 위해 저장소를 무조건 공개하거나 관리자 권한을 부여할 필요는 없다.

기존 글: Docker ECR 사용 시 no basic auth credentials 오류 원인과 해결법은 AWS ECR과 실행 사용자에 따른 인증 차이를 다룬다.

English version: Fix Docker Push Denied: Check Image Tags and Docker Hub Permissions