GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.

Authenticate with the container registry

DETAILS: Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

To authenticate with the container registry, you can use a:

All of these authentication methods require the minimum scope:

For read (pull) access, to be read_registry.
For write (push) access, to be write_registry and read_registry.

To authenticate, run the docker login command. For example:

TOKEN=<token>
docker login registry.example.com -u <username> --password-stdin <<<$TOKEN

Use GitLab CI/CD to authenticate

To use CI/CD to authenticate with the container registry, you can use:

The CI_REGISTRY_USER CI/CD variable.

This variable holds a per-job user with read-write access to the container registry. Its password is also automatically created and available in CI_REGISTRY_PASSWORD.
```
docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin <<<$CI_REGISTRY_PASSWORD
```

A CI job token.

docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin <<<$CI_JOB_TOKEN

A deploy token with the minimum scope of:
- For read (pull) access, read_registry.
- For write (push) access, read_registry and write_registry.
```
docker login $CI_REGISTRY -u $CI_DEPLOY_USER --password-stdin <<<$CI_DEPLOY_PASSWORD
```
A personal access token with the minimum scope of:
- For read (pull) access, read_registry.
- For write (push) access, read_registry and write_registry.
```
docker login $CI_REGISTRY -u <username> -p <access_token>
```