Authenticating with Seal's image registry

Configure your image-pull layer to authenticate against Seal's hosted 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:

Docker

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.

Podman

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.

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:

GitHub Actions

- 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 }}

GitLab CI

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.

Jenkins

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.

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 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:

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, covers the actual reference format and how to use it from a Dockerfile or directly.

Related

• Pulling a sealed base image: what to do once authentication is in place.

• Using Seal Base Images with Kubernetes and Helm: the imagePullSecret-based path for clusters.

• Tokens: 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.