4.2 OCI Container Registry: Repositories, Push & Pull, and Image Management
Key Takeaways
OCIR is an Open Container Initiative (OCI)-compliant registry that supports the Docker V2 API, multi-architecture manifest lists, and Helm charts.
Docker clients log in with the tenancy's Object Storage namespace plus username (namespace/username) and use an auth token as the password.
Each region allows up to 500 repositories using up to 500 GB in total, and each repository can hold up to 100,000 images.
Retention policies delete images that have not been pulled, or not been tagged, for a set number of days, and each region has its own global retention policy.
Image signatures are created with an RSA asymmetric key in OCI Vault; AES symmetric keys cannot be used to sign images.
What OCIR Provides
OCI Container Registry (also called Oracle Cloud Infrastructure Registry, or OCIR) is an Oracle-managed registry for storing, sharing, and managing container images. It is Open Container Initiative compliant, implements the Docker Registry HTTP API V2, and supports:
- Standard
dockerandpodmanpush and pull commands. - Manifest lists (multi-architecture images), so one tag can serve both AMD64 and ARM (Ampere) nodes.
- Helm charts, stored as OCI artifacts.
- Private repositories (authenticated) and public repositories (anyone with the URL can pull).
OCIR is regional. Each region has its own registry endpoint, and a repository lives in one region.
Endpoints and Image Paths
You address a region's registry with its region key, for example iad.ocir.io for Ashburn or phx.ocir.io for Phoenix. A full image path has three parts after the endpoint:
<region-key>.ocir.io/<tenancy-namespace>/<repository-name>:<tag>
iad.ocir.io/ansh81vru1zp/orders/api:2.4.1
The tenancy namespace is the auto-generated Object Storage namespace string shown on the Tenancy Information page. It is not the tenancy name. Repository names can include a path, such as orders/api, to organize images by project.
Authentication: Auth Tokens
To log in from Docker, a user runs docker login iad.ocir.io and enters:
- Username:
<tenancy-namespace>/<username>, for exampleansh81vru1zp/jdoe@acme.com. Older tenancies federated with Oracle Identity Cloud Service use<tenancy-namespace>/oracleidentitycloudservice/<username>. - Password: an auth token generated for the user, not the console password.
Automated systems should avoid long-lived personal tokens where possible. OCI DevOps build pipelines, for example, push to OCIR using the pipeline's resource principal and IAM policies, and Container Instances can store registry credentials in a Vault secret.
IAM Policies for Repositories
Repository access is controlled with the repos resource type:
Allow group Developers to manage repos in compartment AppDev
Allow group Deployers to read repos in compartment AppDev
Allow dynamic-group BuildPipelines to manage repos in compartment AppDev
Pulling needs read access to the repository; pushing needs manage access. Public repositories can be pulled without authentication, so only mark a repository public when the images contain nothing sensitive.
Limits and Private Access
| Limit | Value |
|---|---|
| Repositories per region | Up to 500 |
| Total storage per region | Up to 500 GB (contact Oracle for more) |
| Images per repository | Up to 100,000 |
Resources in a private subnet, such as OKE worker nodes, can pull from OCIR privately through a service gateway in the same region. No internet gateway is needed, and traffic stays on Oracle's network.
Image Management Task 1: Retention Policies
Old development builds accumulate quickly. Image retention policies delete images automatically when they match selection criteria:
- Images that have not been pulled for a certain number of days.
- Images that have not been tagged for a certain number of days.
- Images whose tags are listed as exempt are never deleted.
Each region has one global image retention policy that applies to all repositories. Its default criteria retain all images, so nothing is deleted until you change it. Custom retention policies override the global policy for the repositories you add to them, and only one custom policy can apply to a repository at a time. An hourly process deletes matching images, but a newly created or updated policy is ignored for several hours as a cooling-off period so you can refine its criteria. Because policies are regional, you must create matching policies in every region that holds copies of your images.
Image Management Task 2: Signing and Verification
Supply-chain security requires proof that an image came from your pipeline and was not altered. OCIR supports image signing with a master encryption key from OCI Vault:
- Push the image to OCIR.
- Sign it with an RSA asymmetric Vault key and key version. AES symmetric keys cannot sign images.
oci artifacts container image-signature sign-upload --compartment-id <compartment-ocid> --kms-key-id <key-ocid> --kms-key-version-id <key-version-ocid> --signing-algorithm SHA_224_RSA_PKCS_PSS --image-id <image-ocid>
A signature is tied to the image's OCID, so it applies to that specific push. An image can carry several signatures from different keys. Runtimes can then refuse unsigned images: OKE clusters and OCI Functions applications can be configured with image verification policies that only run images signed by specified Vault keys.
Image Management Task 3: Vulnerability Scanning
You enable scanning by adding an image scanner to a repository. OCIR then uses the Vulnerability Scanning service to:
- Scan every image pushed to the repository.
- Immediately scan the four most recently pushed images if the repository already had images.
- Re-scan automatically when new vulnerabilities are added to the CVE database.
Scan results list the CVEs found in each image. A deployment pipeline can check those results and stop a release that contains critical vulnerabilities.
Making Images Available in Several Regions
Because OCIR is regional, a multi-region or DR design must ensure the standby region can pull the same image versions. A common pattern is for the build pipeline to push each released image to the registry in every target region, and to deploy by image digest rather than a mutable tag so both regions run byte-identical images. Retention policies, signing keys, and scanners must also be configured in each region.
A DevOps engineer runs docker login against iad.ocir.io and enters the tenancy name followed by a username, plus the console password. The login fails. Which credentials does OCIR expect?
The tenancy OCID as the username and an API signing key as the password
The repository name as the username and the user's Console password
The Object Storage namespace plus the username, with an auth token as the password
The region key followed by the username, with a customer secret key as the password
A security team wants OKE to run only container images that their release pipeline has signed. Which approach meets this requirement with OCI-native features?
Make the repositories public so every image has a verifiable public URL
Sign images with an AES-256 key in Vault and share that key with the worker nodes
Use a retention policy that deletes any image that has not been pulled for 30 days
Sign images with an RSA key from Vault and enforce an image verification policy
A repository already holds hundreds of images when the team adds an image scanner to it. Which images are scanned right away?
The four most recent images, and every image pushed afterward
All images in the repository, starting with the oldest
Only images that have been pulled in the last 30 days
No existing images; only images pushed after the scanner is added
Sections you finish are checked off in the contents.