Limit GitLab deployment credentials to registry pulls

Use the registry-read scope when a deployment system only needs to download container images.

Source facts

GitLab’s deploy-token documentation distinguishes read_registry for pulling images from write_registry for pushing them. Deploy tokens can be created at project or group scope, and an expiration date can be defined. GitLab documents revocation when a token is no longer required. A deploy token is not a general GitLab public API credential, although some package-registry endpoints support it.

Source: GitLab — Deploy tokens.

Applicability

Use this guide for a deployment consumer that only pulls from the relevant GitLab container registry. Check the current GitLab version, registry location, and project or group boundary.

DSE recommendation

DSE recommends issuing a purpose-specific token for the deployment consumer and granting only the scope needed for its task. Prefer the narrowest practical project boundary, record the owner and expiry, and prepare replacement before expiry affects a deployment. Store the token in the deployment platform’s approved credential facility. Keep it out of image layers, source files, command transcripts, and routine support records. Retire the old credential after verifying that the replacement works for the intended consumer.

Verification

Pull an approved test image through the deployment workflow. In a controlled test, confirm that the pull-only credential cannot push an image or access an unrelated project. Verify replacement and revocation behavior, then record the token identifier, scopes, owner, and expiry without storing its value.

Official reference

GitLab — Deploy tokens. Reviewed October 14, 2026.