# Ensure there are no registry set as Public

- Source: https://support.icompaas.com/support/solutions/articles/a_178602308623696-ensure-there-are-no-registry-set-as-public
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Utho Cloud](https://support.icompaas.com/support/solutions/c_1786022244474917) › [Utho Checks](https://support.icompaas.com/support/solutions/folders/utho-checks)
- Last updated: 2026-08-06
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

## Description

Utho Container Registry stores Docker/OCI images in repositories, each with a visibility of Public or Private. A Public repository lets anyone pull its images without authentication; a Private repository requires the registry credentials (retrieved via View Credentials) to pull or push.

This control checks that repositories holding internal images are Private and that none have been flipped to Public. Newly created Utho repositories default to Private, so the risk is a repository that was deliberately or accidentally made Public.

If specific images are genuinely meant to be shared, they should live in a dedicated public repository, with all internal images kept Private.

-   Repositories set to Public that expose internal images to anonymous pulls
    
-   Proprietary source, binaries, or secrets/config baked into image layers being downloadable
    
-   Push/pull workflows relying on anonymous access instead of registry credentials
    

## Rationale

A public container registry lets anyone pull your images, exposing proprietary source, binaries, and any secrets or configuration baked into the layers, and hands an attacker a blueprint of your stack — versions, dependencies, internal service names — to plan further attacks.

Keeping repositories Private makes possession of the registry credentials a precondition for pulling images, which is the baseline expectation for anything containing internal code.

-   Image layers frequently contain embedded secrets, config, and proprietary code
    
-   Public images reveal exact component versions an attacker can target
    
-   Anonymous pull removes any audit trail of who obtained an image
    

## Impact

Pros:

-   Internal images can only be pulled with valid registry credentials
    
-   Removes anonymous exposure of code, binaries, and baked-in secrets
    
-   Genuinely public images are isolated to a dedicated repository
    

Cons:

-   Every push/pull workflow must authenticate with the registry credentials
    
-   Any consumer that relied on anonymous public pulls must be updated
    
-   Sharing an image publicly now requires publishing it to a separate public repository
    

## Default Value

By default, all newly created Utho Container Registry repositories are set to Private; only repositories explicitly switched to Public are at risk.

## Pre-Requisite

-   Utho console access to the account/team that owns the registry
    
-   The registry credentials (from View Credentials) so push/pull workflows can authenticate once repositories are Private
    
-   Awareness of which images (if any) are genuinely intended to be public
    

## Remediation

### Test Plan

Using the Utho Console:

1.  Sign in to the Utho console and open Container Registry.
    
2.  Review the repository list and read each repository's visibility (Public or Private).
    
3.  As a live check, attempt an unauthenticated docker pull of an image and confirm it is refused.
    
4.  Repeat for every repository.
    
5.  Pass: every repository holding internal images is Private and an unauthenticated pull returns an authentication-required error.
    
6.  Fail: any internal repository is marked Public, or an unauthenticated pull succeeds.
    

Using the Utho API:

Repository visibility is read in the Utho console; the exact api.utho.com/v2 registry path that returns a repository's visibility could not be confirmed against Utho's published API reference, so no read command is given — verify at utho.com/api-docs before scripting.

### Implementation Steps

Using the Utho Console:

1.  Open Container Registry in the Utho console and select the repository.
    
2.  In the repository's visibility settings, set it to Private (use the Make Private button if it is currently Public).
    
3.  Repeat for every repository and confirm none remain Public.
    
4.  Use View Credentials to retrieve the registry username/password and update all push/pull workflows to authenticate with those credentials instead of relying on anonymous pulls.
    
5.  If specific images must be shared, publish only those to a dedicated separate public repository and keep all internal images Private.
    

Using the Utho API:

This fix is performed in the Utho console (Container Registry → select repository → Make Private). Utho's Developer API may cover registry management, but the exact endpoint to change repository visibility could not be confirmed against the published spec, so no command is provided.

### Backout Plan:

1.  If a legitimate consumer breaks after a repository is made Private, do not simply re-open it — give the consumer the registry credentials (View Credentials) and update its docker login / pull config.
    
2.  If an image genuinely needs to be public, move that specific image to a dedicated public repository rather than making the internal repository Public.
    
3.  Only with documented, reviewed approval should a repository be returned to Public; record who approved it and revert once the authenticated path is in place.
    

## References:

1.  [Utho Docs – Container Registry](https://utho.com/docs/products/storage/container-registry)
    
2.  [Utho Docs – Container Registry FAQs](https://utho.com/docs/products/storage/container-registry/faqs/)
    
3.  [Utho Docs – Container Registry Quick Start](https://utho.com/docs/products/storage/container-registry/getting-started/quick-start/)
    
4.  [Utho Docs – View Registry Credentials](https://utho.com/docs/products/storage/container-registry/how-tos/view-credentials/)

## 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.