# Ensure Kubernetes Clusters Use An Authorized Container Registry

- Source: https://support.icompaas.com/support/solutions/articles/ensure-kubernetes-clusters-use-an-authorized-container-registry
- 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 verifies that workloads on a DOKS cluster pull container images from an approved, authorized registry rather than arbitrary public registries. On DigitalOcean the native building block is DigitalOcean Container Registry (DOCR) integration, which wires registry pull credentials into the cluster's namespaces so pods can pull from the private registry without hand-managed secrets.

Note the honest scope: DOKS provides registry integration (authenticated pulls from DOCR) but does not, on its own, enforce a registry allowlist. Restricting pods to only the authorized registry requires an admission controller (for example Kyverno or OPA Gatekeeper) that you install into the cluster; there is no DigitalOcean API for that policy. This rule therefore has two parts: confirm the authorized registry is integrated, and confirm an admission policy restricts image sources.

-   Clusters with no authorized DOCR integration configured.
    
-   Pods referencing images from unrestricted public registries (e.g. arbitrary Docker Hub repos).
    
-   Clusters with no admission-control policy restricting permitted image registries.
    

## Rationale

Allowing pods to pull from any public registry exposes the cluster to supply-chain risk: a compromised, typosquatted, or malicious public image can run in the cluster with no internal review or vulnerability scanning. Constraining pulls to an organization-approved registry ensures every image passes through a controlled, scannable pipeline before it can be deployed.

DOCR integration provides the authenticated-pull half of this (private, credentialed access wired into namespaces), and an admission controller provides the enforcement half (rejecting pods whose images come from anywhere else). Both are needed for a real guarantee.

-   Blocks deployment of unvetted or malicious public images.
    
-   Channels all images through a scannable, controlled registry.
    

## Impact

Pros:

-   Reduces container supply-chain attack surface.
    
-   Centralizes images in a controlled, scannable registry.
    
-   DOCR integration removes hand-managed imagePullSecrets across namespaces.
    

Cons:

-   Enforcement requires deploying and maintaining a third-party admission controller (no DO API).
    
-   Teams must mirror or rebuild needed public images into the approved registry.
    
-   An overly strict policy can block legitimate images and needs careful exception handling.
    
-   DOCR usage may incur additional storage/registry cost.
    

## Default Value

DigitalOcean Container Registry integration is disabled by default (registry\_enabled is false until you add it), and DOKS does not restrict image sources out of the box.

## Pre-Requisite

-   A DigitalOcean Container Registry containing the authorized images.
    
-   Control Panel access to the cluster Settings, or an API token / authenticated doctl, to add the registry integration.
    
-   kubectl (cluster-admin) access to deploy an admission controller such as Kyverno or OPA Gatekeeper for allowlist enforcement.
    
-   An inventory of workloads and the registries their images currently reference.
    

## Remediation

### Test Plan

Using the DigitalOcean Control Panel:

1.  Sign in to cloud.digitalocean.com and open Kubernetes; select the cluster and open the Settings tab.
    
2.  In the 'DigitalOcean Container Registry Integration' section, confirm an authorized registry is integrated.
    
3.  Separately, using kubectl, confirm an admission controller (Kyverno/Gatekeeper) with a registry-allowlist policy is installed and enforcing.
    
4.  Pass: the authorized registry is integrated AND an admission policy restricts pulls to it.
    
5.  Fail: no authorized registry is integrated, or pods can pull from unrestricted registries because no allowlist policy is enforced.
    

Using doctl or the API:

Confirm the DOCR integration on the cluster; allowlist enforcement is verified in-cluster with kubectl, not via a DO API. (doctl's --format has no RegistryEnabled column, so read the full JSON with -o json.)

doctl kubernetes cluster get <cluster-id> -o json | jq '.\[0\].registry\_enabled'

curl -s -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/kubernetes/clusters/$CLUSTER\_ID" | jq '.kubernetes\_cluster.registry\_enabled'

kubectl get pods -A -o jsonpath='{range .items\[\*\]}{.spec.containers\[\*\].image}{"\\n"}{end}' | sort -u   # review image sources against the approved registry

Pass if registry\_enabled = true AND all in-use images resolve to the approved registry with an admission policy enforcing it. Fail if registry\_enabled = false, or images reference unauthorized registries, or no allowlist policy is enforced.

### Implementation Steps

Using the DigitalOcean Control Panel:

1.  Open the cluster's Settings tab; in 'DigitalOcean Container Registry Integration', click Edit, select the authorized registry, and Save. This injects pull credentials into the cluster namespaces.
    
2.  Install an admission controller (e.g. Kyverno or OPA Gatekeeper) via kubectl/Helm.
    
3.  Apply a policy that only admits pods whose images come from the approved registry host, and set it to enforce (deny) mode.
    
4.  Rebuild or mirror any workload images currently pulled from public registries into the approved registry and redeploy.
    

Using doctl or the API:

DOCR integration is available via doctl/API; the registry-allowlist policy itself is applied in-cluster with kubectl (no DigitalOcean API exists for it).

doctl kubernetes cluster registry add <cluster-id>

curl -s -X POST -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -H 'Content-Type: application/json' -d '{"cluster\_uuids":\["'$CLUSTER\_ID'"\]}' "https://api.digitalocean.com/v2/kubernetes/registry"

kubectl apply -f allowed-registries-policy.yaml   # Kyverno/Gatekeeper policy restricting image registries

### Backout Plan:

1.  To remove enforcement, delete or set the admission policy to audit mode: kubectl delete -f allowed-registries-policy.yaml.
    
2.  To remove the DOCR integration: doctl kubernetes cluster registry remove <cluster-id> (or DELETE /v2/kubernetes/registry with the cluster UUID).
    
3.  Revert workloads to their prior image references if the change caused pull failures.
    

## References:

1.  [DOKS - Integrate with a DigitalOcean Container Registry](https://docs.digitalocean.com/products/kubernetes/how-to/integrate-with-docr/)
    
2.  [DigitalOcean Container Registry docs](https://docs.digitalocean.com/products/container-registry/)
    
3.  [doctl kubernetes cluster registry reference](https://docs.digitalocean.com/reference/doctl/reference/kubernetes/cluster/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.