CI/CD

Container Registry in CI/CD pipelines

This guide covers authenticating to Thalassa Cloud Container Registry from CI/CD pipelines using access credentials and service accounts.

Credential scopes

Access credentials must include a container registry scope:

Scope	Access	Typical use
`containerRegistry`	Push and pull	Build pipelines that push images
`containerRegistry:all`	Push and pull	Same as above
`containerRegistry:pull`	Pull only	Deploy pipelines and promotion stages

Create separate credentials for build and deploy stages. Deploy pipelines should use pull-only scope.

User sessions and IAM policies can also grant push and pull on registry resources. See Access control for policy-based access.

Docker login in a pipeline

Most CI systems support running docker login before push or pull:

docker login registry.nl-01.thalassa.cloud \
  -u "$REGISTRY_USERNAME" \
  -p "$REGISTRY_PASSWORD"

Store REGISTRY_USERNAME and REGISTRY_PASSWORD as protected CI variables — never commit credentials to source control.

Build and push workflow

A typical build pipeline:

# Authenticate
docker login registry.nl-01.thalassa.cloud \
  -u "$REGISTRY_USERNAME" \
  -p "$REGISTRY_PASSWORD"

# Build
docker build -t my-app:$CI_COMMIT_SHA .

# Tag with registry path
docker tag my-app:$CI_COMMIT_SHA \
  registry.nl-01.thalassa.cloud/acme-platform/my-app:$CI_COMMIT_SHA

docker tag my-app:$CI_COMMIT_SHA \
  registry.nl-01.thalassa.cloud/acme-platform/my-app:latest

# Push
docker push registry.nl-01.thalassa.cloud/acme-platform/my-app:$CI_COMMIT_SHA
docker push registry.nl-01.thalassa.cloud/acme-platform/my-app:latest

Tag images with commit SHA or build ID for traceability. Avoid overwriting latest in production namespaces without a promotion step.

Pull-only deploy workflow

Deploy pipelines that only need to verify or promote images:

docker login registry.nl-01.thalassa.cloud \
  -u "$REGISTRY_USERNAME" \
  -p "$REGISTRY_PASSWORD"

docker pull registry.nl-01.thalassa.cloud/acme-platform/my-app:$IMAGE_TAG

Use a credential with containerRegistry:pull scope.

Service accounts

For long-running automation, create a service account with an access credential scoped to the minimum required registry permissions. Bind registry:developer or a custom IAM policy for API-level namespace management if the pipeline also creates namespaces.

OIDC workload identity

For GitLab CI, GitHub Actions, and other OIDC-capable platforms, you can authenticate without storing long-lived secrets using Workload Identity Federation. Configure a federated identity with container registry scopes and exchange the OIDC token for registry access.

Recommended practices

Practice	Rationale
Separate build and deploy credentials	Limit blast radius if a deploy credential leaks
Pull-only for deploy	Prevents accidental image overwrites from deploy pipelines
Tag with immutable identifiers	SHA or build ID enables rollback and audit
Use retention policies	Automatically prune CI-generated tags to control storage costs