> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/setup-containers/seal-base-images/authenticating.md).

# Authenticating with Seal's image registry

Seal publishes its sealed base images to a dedicated registry namespace. Pulling from it requires credentials issued by Seal for your tenant. Once your image-pull layer (CI build agent, Kubernetes node, developer workstation) is authenticated, the registry behaves like any other OCI-compliant registry: the same `docker pull` / `podman pull` / `crane pull` flow works.

## What you need

* The Seal-issued **username** and **password** (or **registry token**) for your tenant. These are provided by your Seal account team when Seal Base Images is enabled for your tenant. The credentials are tenant-scoped, not user-scoped; treat them as a deployment secret.
* The Seal **registry hostname** for image pulls. Your Seal account team provides the canonical hostname for your tenant; the rest of this chapter uses `<seal-registry>` as a placeholder.

The credentials authorize pulls of any Seal Base Image your tenant is entitled to. They do not authorize pushes; Seal manages the publish side.

## Logging in from the Docker CLI

For a developer workstation or a CI agent that runs `docker` or `podman` commands directly:

{% tabs %}
{% tab title="Docker" %}

```bash
docker login <seal-registry> -u <seal-username>
# enter the password when prompted; do not echo it to the terminal
```

A successful login writes the credentials to `~/.docker/config.json`. Subsequent `docker pull` commands against `<seal-registry>/...` use the stored credentials automatically.
{% endtab %}

{% tab title="Podman" %}

```bash
podman login <seal-registry> -u <seal-username>
```

Podman stores credentials at `${XDG_RUNTIME_DIR}/containers/auth.json` by default. The same login covers `podman pull` and `buildah pull`.
{% endtab %}
{% endtabs %}

In CI, set the credentials through your CI's secret store rather than committing them. Most CI systems have a built-in registry-login step:

{% tabs %}
{% tab title="GitHub Actions" %}

```yaml
- name: Log in to Seal's image registry
  uses: docker/login-action@v3
  with:
    registry: <seal-registry>
    username: ${{ secrets.SEAL_REGISTRY_USERNAME }}
    password: ${{ secrets.SEAL_REGISTRY_PASSWORD }}
```

{% endtab %}

{% tab title="GitLab CI" %}

```yaml
before_script:
  - docker login <seal-registry> -u "$SEAL_REGISTRY_USERNAME" -p "$SEAL_REGISTRY_PASSWORD"
```

Configure `SEAL_REGISTRY_USERNAME` and `SEAL_REGISTRY_PASSWORD` as masked, protected GitLab CI/CD variables.
{% endtab %}

{% tab title="Jenkins" %}

```groovy
pipeline {
  agent any
  environment {
    SEAL_REGISTRY = credentials('seal-registry-credentials')
  }
  stages {
    stage('Log in') {
      steps {
        sh '''
          echo "$SEAL_REGISTRY_PSW" | docker login <seal-registry> \
            -u "$SEAL_REGISTRY_USR" --password-stdin
        '''
      }
    }
  }
}
```

The `credentials()` binding turns a "Username with password" credential into the `_USR` and `_PSW` paired variables.
{% endtab %}
{% endtabs %}

## Kubernetes pull secrets

For Kubernetes clusters where nodes pull the image at pod-launch time, authentication is configured through an `imagePullSecret` rather than a per-user login. See [Using Seal Base Images with Kubernetes and Helm](/setup-containers/seal-base-images/kubernetes.md) for the manifests; the secret-creation step is documented there.

## Credential rotation

Treat Seal registry credentials like any other long-lived deployment secret:

* Store them in your secret manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Kubernetes Secret of type `kubernetes.io/dockerconfigjson`).
* Inject them into the image-pull layer at runtime rather than baking them into images or workflow files.
* Rotate on the cadence your security policy requires; coordinate the rotation with your Seal account team so the new credentials are issued before the old ones are revoked.

If a credential is compromised, contact your Seal account team to revoke and reissue. The blast radius is limited to image pulls — the credential does not grant access to the rest of the Seal Platform.

## Verifying authentication

A quick `docker pull` against any sealed image confirms the login worked:

```bash
docker pull <seal-registry>/<image>:<tag>
```

If the credentials are valid and your tenant is entitled to the image, the pull succeeds. A `401 Unauthorized` means the credentials are wrong or have expired; a `403 Forbidden` typically means the credentials are valid but the tenant is not entitled to the image you requested. Reach out to your Seal account team in either case.

The next page, [Pulling a sealed base image](/setup-containers/seal-base-images/pulling.md), covers the actual reference format and how to use it from a `Dockerfile` or directly.

## Related

* [Pulling a sealed base image](/setup-containers/seal-base-images/pulling.md): what to do once authentication is in place.
* [Using Seal Base Images with Kubernetes and Helm](/setup-containers/seal-base-images/kubernetes.md): the `imagePullSecret`-based path for clusters.
* [Tokens](/getting-started/tokens.md): the broader token-management page for the Seal Platform. Seal registry credentials are tenant-level and distinct from the per-user platform tokens described there.