Skip to main content

More Info:

Restrict image pulls to approved container registries. Use OCI IAM policies to control access to OCI Container Registry, or follow vendor best practices for third-party registries.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify all registries currently in use (any machine with kubectl access)
    From this list, extract and note the registry domains (e.g., phx.ocir.io, iad.ocir.io, docker.io, gcr.io).
  2. Define the approved registries list (offline / documentation step)
    With your security/operations stakeholders, create or confirm a documented list of approved registries (e.g., specific OCIR regions and/or vetted third‑party registries). Explicitly include any allowed mirrors and namespaces (tenancy/compartment-specific OCIR repos, org-specific Docker Hub orgs, etc.).
  3. Review OCI IAM policies for OCI Container Registry (any machine with OCI CLI configured)
    List policies at the tenancy and relevant compartments and inspect for OCIR access:
    Look in each policy’s statements for rules containing artifacts-repository, ocir, or container image. Confirm that:
    • Only intended groups/dynamics groups can read/pull from approved OCIR repos.
    • There are no broad permissions like inspect all-artifacts-repositories in tenancy or read all-resources in tenancy that effectively allow unapproved registries or repos.
  4. Tighten OCI IAM policy scope if required (console or IaC)
    In the OCI Console or your IaC:
    • Restrict OCIR access policies to approved compartments, repositories, and groups only.
    • Remove or replace overly permissive policies discovered in step 3 with least‑privilege equivalents that reference only the approved OCIR repos and compartments.
  5. Review third‑party registry configurations and credentials (where configured)
    • On the CI/CD platform(s): review registry integrations and secrets; ensure they point only to the approved registries from step 2.
    • In OCI (if using secrets/OKE node pool configs): review any registry credentials stored in OCI Vault or node pool configurations to ensure they reference only approved registries.
      Follow each vendor’s security best practices (RBAC, tokens with minimal scope, IP allow‑listing, content trust, etc.) for those registries.
  6. Verify cluster workloads use only approved registries (any machine with kubectl access)
    Re-run:
    Compare each image’s registry domain against the approved list from step 2 and update any Deployment/DaemonSet/StatefulSet manifests or Helm values that still reference unapproved registries.
kubectl cannot be used to restrict which container registries are allowed for this finding, because the control lives in the cloud provider / managed control-plane configuration and underlying IAM, not in Kubernetes API objects. Make the changes in your cloud console/CLI or IaC (OCI IAM policies or third‑party registry controls) as described in the Manual Steps section.
How to interpret the output
  • The === Unique registries used by workload images === section lists all registries currently in use.
  • Any registry in that list that is not part of your formally approved registries (e.g., your OCI Container Registry hostnames and any vetted third‑party registries) indicates a potential problem and should be reviewed.
  • If you set APPROVED_REGISTRIES, any line under === Registries in use that are NOT in the approved list === is a candidate violation of “Minimize Container Registries to only those approved” and should trigger:
    • Review of the workload using that image.
    • A decision whether to add the registry to the approved list or migrate the image to an approved registry and restrict access via OCI IAM / vendor policies.