# Ensure Container Registries Are Not Configured As Read-Only Unless Intended - Source: https://support.icompaas.com/support/solutions/articles/ensure-container-registries-are-not-configured-as-read-only-unless-intended - Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules) - Last updated: 2026-08-13 - Publisher: iCompaas, Inc. (https://www.icompaas.com) ## Description This rule confirms that a DigitalOcean Container Registry used for active image publishing remains writable by your authorized CI/CD pipelines and has not been effectively locked to read-only in a way that would silently break deployments. An important mapping note for DigitalOcean: unlike some registries, DigitalOcean Container Registry has no registry-level read-only toggle. The registry object exposed by the API and Control Panel carries only name, region, storage usage, and subscription details, so 'read-only' is not a property of the registry itself. Where the read-only distinction actually lives is in the registry credentials: DigitalOcean docker-credentials are read-only by default and only grant push access when read/write is explicitly requested (doctl registry docker-config --read-write, or ?read\_write=true on the API). A registry therefore becomes effectively read-only when the pipeline that publishes to it was configured with read-only credentials. The rule reviews how each registry is used and how its publishing pipelines authenticate, and flags cases where a registry that is meant to receive images can only be pulled from because the CI/CD credentials in use are read-only. - A registry intended for active publishing whose CI/CD pipeline authenticates with read-only docker-credentials (no read/write requested). - Automation or deploy jobs failing on 'denied: requested access to the resource is denied' / push authorization errors against a registry that should be writable. - Read/write credentials that were intended for a publishing pipeline but were generated without the read/write flag. ## Rationale Registry credentials are the real access-mode control on DigitalOcean, and because they default to read-only, it is easy to wire a build pipeline with credentials that can pull but not push. When that happens the failure is a deploy-time push rejection whose root cause (a credential scoped read-only) is not obvious from the registry view, since the registry looks identical whether or not any pipeline can write to it. The result is broken releases and time lost chasing a configuration that appears fine. Correctly scoping credentials also has a security dimension: read-only credentials are the right choice for pull-only consumers (production hosts, Kubernetes nodes pulling images), while read/write credentials should be reserved for the specific pipelines that publish. Verifying that each consumer holds the minimum access it needs both keeps deployments working and avoids handing push rights to systems that only need to pull. - DigitalOcean docker-credentials default to read-only, so a publishing pipeline can silently lack push rights. - The registry object itself has no read-only field, so the misconfiguration is invisible from the registry view. - Scoping read-only to pull-only consumers and read/write to publishers is least-privilege done right. ## Impact Pros: - Publishing pipelines keep working; no surprise push-denied failures at deploy time. - Pull-only consumers hold read-only credentials, minimizing where push rights are distributed. - Clear, intentional separation between who can publish images and who can only consume them. Cons: - DigitalOcean provides no registry-level flag to assert this state, so verification relies on auditing how credentials were generated and stored. - Read/write credentials embed a DigitalOcean API token and must be protected as secrets in CI. - Rotating or re-scoping credentials requires updating every pipeline that uses them. ## Default Value DigitalOcean Container Registry has no registry-level read-only setting; registry docker-credentials are read-only by default and grant push access only when read/write is explicitly requested (doctl registry docker-config --read-write or ?read\_write=true). ## Pre-Requisite - DigitalOcean Control Panel access with permission to view and manage the Container Registry (Owner or an equivalent member role). - A DigitalOcean API token, or doctl authenticated (doctl auth init), able to read the registry and generate docker-credentials. - Knowledge of which pipelines publish images (need read/write) versus which systems only pull (need read-only). - Access to the CI/CD secret store to inspect how each pipeline's registry credentials were generated. ## Remediation ### Test Plan Using the DigitalOcean Control Panel: 1. Sign in to cloud.digitalocean.com and open Container Registry from the left menu. 2. Confirm the registry exists and note its name; there is no read-only toggle to inspect here because DigitalOcean does not expose one at the registry level. 3. Open your CI/CD system's registry configuration (for example the login/docker-config step) for the pipeline that publishes to this registry. 4. Verify that step requests read/write credentials (for example doctl registry docker-config --read-write, or docker credentials generated with read\_write=true), not the default read-only credentials. 5. Confirm that pull-only consumers (production hosts, Kubernetes clusters) are configured with default read-only credentials. 6. Pass: The publishing pipeline authenticates with read/write registry credentials and can push, while pull-only consumers use read-only credentials. 7. Fail: A pipeline that must publish is configured with read-only (default) credentials, so pushes to the registry are denied. Using doctl or the API: Confirm the registry exists and inspect the access mode of the credentials your pipelines use (the registry object has no read-only field). doctl registry get curl -s -X GET "https://api.digitalocean.com/v2/registry" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" doctl registry docker-config --read-write curl -s -X GET "https://api.digitalocean.com/v2/registry/docker-credentials?read\_write=true" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" The registry response contains no read\_only property, so pass/fail is judged on credentials: pass if the publishing pipeline uses read/write credentials (docker-config --read-write / read\_write=true) and pull-only consumers use the default read-only credentials; fail if a pipeline that must publish is using default read-only credentials. ### Implementation Steps Using the DigitalOcean Control Panel: 1. Sign in to cloud.digitalocean.com and open Container Registry to confirm the target registry name. 2. In your CI/CD system, locate the step that logs in to or generates credentials for the registry. 3. Change that step to request read/write credentials: run doctl registry docker-config --read-write (or doctl registry login, which authenticates the local Docker client for push), and store the resulting config as a protected CI secret. 4. Re-run the pipeline and confirm the image push now succeeds. 5. Leave pull-only consumers (production hosts, DOKS clusters) on the default read-only credentials so only publishing pipelines hold push rights. Using doctl or the API: Registry access mode is controlled through credentials, not a registry setting; use doctl or the docker-credentials endpoint to issue read/write credentials for publishers. doctl registry docker-config --read-write > registry-rw-config.json curl -s -X GET "https://api.digitalocean.com/v2/registry/docker-credentials?read\_write=true" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -o registry-rw-config.json doctl registry login ### Backout Plan: 1. For any consumer that only needs to pull, regenerate default (read-only) credentials with doctl registry docker-config (omit --read-write) or GET /v2/registry/docker-credentials without read\_write=true, and replace the read/write secret with the read-only one. 2. Revoke or rotate the DigitalOcean API token backing any read/write credentials that are no longer needed. 3. Update the affected pipelines to use the restored read-only credentials and re-run them to confirm pull-only behavior. ## References: 1. [DigitalOcean Container Registry](https://docs.digitalocean.com/products/container-registry/) 2. [How to Use CI/CD Systems with Your Container Registry](https://docs.digitalocean.com/products/container-registry/how-to/set-up-ci-cd/) 3. [doctl registry docker-config](https://docs.digitalocean.com/reference/doctl/reference/registry/docker-config/) 4. [Container Registry API Reference](https://docs.digitalocean.com/reference/api/reference/container-registry/) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.