The path
Upstream images → curated base repos → DevOps build / CI → scan → sign (Vault key) → OCIR (private)
→ OKE / Container Instances → signature verification at deploy → runtime scanning
1. Repository design
| Decision | Common choice |
|---|---|
| Visibility | Private repositories only (public only for intentionally public images) |
| Location | Same region as the workloads; replicate/push to DR region too |
| Layout | Compartment per environment or team; repositories team/app; base/ for curated base images |
| Push rights | CI/DevOps pipeline identity only (manage repos scoped to compartments) |
| Pull rights | OKE nodes / workloads via dynamic groups or workload identity (read repos) |
Allow dynamic-group oke-nodes-prod to read repos in compartment prod-images
Allow dynamic-group devops-build to manage repos in compartment prod-images
2. Curated base images
- Mirror approved base images (Oracle Linux slim, distroless, language runtimes) into
base/repositories on a schedule. - Builds use only
base/images, pinned by version (and digest for critical apps). - Rebuild applications when a base image is updated.
3. Scanning
The Vulnerability Scanning Service scans OCIR images when you create a container scan target for a compartment/repositories with a scan recipe. Findings show CVEs by severity per image.
- Scan in CI too (before push), and fail builds above an agreed severity with fixes available.
- Route findings to owners with SLAs; Cloud Guard can raise problems from scanning results.
4. Sign images with Vault keys
Use an asymmetric key in OCI Vault (RSA, signing usage) and sign after push:
oci artifacts container image-signature sign-upload --compartment-id $C \
--kms-key-id $SIGNING_KEY --kms-key-version-id $KEY_VERSION --signing-algorithm SHA_256_RSA_PKCS_PSS \
--image-id $IMAGE_OCID --description "release 1.4.2 signed by devops-prod"
Keep the signing key in a vault the pipeline can use (use keys) but developers can't.
5. Enforce verification on OKE
OKE clusters can have an image verification policy that only allows images signed by specified Vault keys to run (configured on the cluster's image policy settings). Start in a non-prod cluster, verify all system and add-on images are covered or exempt as the feature allows, then enable in production.
Complement with an admission policy (Kyverno/Gatekeeper) allowing only your OCIR registry paths.
6. Retention and immutability
- Retention policies on repositories to delete untagged and old images.
- Release tags never reused. Deploy by digest or immutable version tags.
- Keep enough history for rollback (e.g. last 10 release images).
7. Runtime
Inventory of which image digests run where (kubectl + labels, or a scanner), so a new CVE maps to workloads quickly; Cloud Guard and scanning for running hosts.
Design review questions
- Can anyone deploy an image from Docker Hub or an unknown registry?
- Who can push to production repositories, and who holds the signing key?
- How long from a critical base-image CVE to all affected services redeployed?
Warning
Enabling signature verification before every image is signed can stop node add-ons or system pods from starting after an upgrade. Inventory every image the cluster runs and test in non-prod first.
Checklist
- Private OCIR repos, compartment layout, least-privilege push/pull
- Curated, pinned base images
- Vulnerability scanning in OCIR and CI, findings owned
- Images signed with Vault keys in the pipeline
- OKE image verification + registry allow-list
- Retention, immutable tags and runtime inventory