Managing Custom Gold Images on OCI for Secure and Compliant Compute Launches

Enterprise cloud environments often need more than a standard operating system image. Security, compliance, audit, and platform engineering teams commonly require virtual machines to be launched only from approved “gold” images that include required hardening, security agents, baseline configuration, monitoring, and operational controls.

This is especially important in regulated environments where public cloud images may not meet internal compliance requirements out of the box. While public platform images are useful for general-purpose workloads, many enterprises need a stronger operating model: users should launch compute instances only from approved private custom images, and platform teams should have a scalable way to refresh, retire, and govern those images over time.

This blog walks through a practical approach for managing custom images on Oracle Cloud Infrastructure, using compartment design and IAM policies to separate image administration from controlled VM launches.

The enterprise requirement

Allow users to create Compute instances only from approved private custom images, and prevent the use of non-approved images for workload deployment.

The approved images, often called gold images, typically include:

• Required security agents
• OS hardening
• Endpoint protection
• Logging and monitoring configuration
• Patch baselines
• Configuration management tooling
• Enterprise-specific compliance settings

The goal is not just to make approved images available. The goal is to make approved images the only viable source for standard users launching Compute instances.

Governance overview

Separate the environment into at least two compartments:

1. VM deployment compartment

This is where application teams or infrastructure users create and manage Compute instances. In this example, we call it compartment1.

2. Approved image compartment

This is where custom gold images are stored and maintained by a restricted image administration team. In this example, we call it compartment2.

Also use two types of groups:

1. VMLaunchers

Users who are allowed to create Compute instances, but only using approved images exposed to them.

2. ImageAdmin

Optional administrative group responsible for creating, updating, tagging, publishing, and retiring approved custom images.

At a high level, VMLaunchers receive permissions to create and manage instances in the VM deployment compartment, use the required networking and block volume resources, and read instance images only from the approved image compartment.

Why use custom images?

Custom images help standardize workload deployment. Instead of every project team manually installing security tools, configuring agents, applying hardening scripts, or relying on post-launch remediation, the image itself becomes part of the control plane.

A well-managed image pipeline can ensure that every server starts from a known baseline. For regulated or security-sensitive workloads, this helps reduce several risks:

• Launching servers without required agents
• Deploying outdated OS versions
• Inconsistent hardening between teams
• Manual configuration drift
• Delayed remediation after instance creation
• Audit gaps around approved operating system sources

Custom images also simplify operations. Platform teams can build, validate, publish, and retire images on a regular cadence, while application teams consume approved images without needing to understand every baseline control embedded inside them.

Step 1: Create a launcher group

Create a group for users who should be allowed to launch VMs from approved custom images.

Example group:

VMLaunchers

Add users to this group only if they should be able to create Compute instances in the approved VM deployment compartment.

Managing IAM groups in OCI:

Managing Groups

Step 2: Grant VM permissions in the deployment compartment

In the compartment where users are allowed to create virtual machines, grant the VMLaunchers group the permissions needed to manage instances and use the supporting network and storage resources.

Example compartment:

compartment1

Example policies:

Allow group VMLaunchers to manage instances in compartment compartment1

Allow group VMLaunchers to use virtual-network-family in compartment compartment1

Allow group VMLaunchers to use volume-family in compartment compartment1

These policies allow users in the VMLaunchers group to create and manage Compute instances, attach the instances to the required virtual cloud network resources, and use block volume resources in the deployment compartment.

OCI common IAM policies, including Compute instance launch policies and scoped compartment examples:

Common Policies

Step 3: Store approved custom images in a dedicated compartment

Create or designate a separate compartment for approved custom images.

Example compartment:

compartment2

This compartment should be controlled by the platform or image administration team. Standard VM launch users should not be able to create, delete, or modify images in this compartment.

The custom images stored here should represent the approved operating system baselines. For example:

• Oracle Linux gold image
• RHEL gold image
• Windows Server gold image
• Hardened application base image
• Region-specific image copies
• Versioned monthly or quarterly image releases

Creating custom Compute images in OCI:

Creating Custom Images

Step 4: Grant image read access only to the approved image compartment

Now grant the VMLaunchers group permission to read instance images from the approved image compartment.

Example policy:

Allow group VMLaunchers to read instance-images in compartment compartment2

This allows users to select approved custom images stored in compartment2 when creating instances in compartment1.

The design intent is straightforward:

• Users can create VMs in the deployment compartment.
• Users can use networking and storage in the deployment compartment.
• Users can read images only from the approved image compartment.
• Users do not receive broad image read access across the tenancy

Step 5: Use defined tags for image lifecycle and approval state

For larger environments, image lifecycle management becomes important. Enterprises may have many image variants across multiple regions, operating systems, architectures, and refresh cycles.

Defined tags can help represent image approval and lifecycle state.

Example tag namespace:

GoldImage

Example defined tags:

GoldImage.Approved = true

GoldImage.Status = active

GoldImage.OS = rhel9

GoldImage.Owner = platform-engineering

GoldImage.Release = 2026-07

Defined tags are preferable to freeform tags for governance because they are centrally managed and more suitable for access-control and policy use cases.

A tag-based image access concept could look like this:

Allow group VMLaunchers to read instance-images in tenancy

  where all {

    target.resource.tag.GoldImage.Approved = 'true',

    target.resource.tag.GoldImage.Status = 'active'

  }

Managing access with tags:

Using Tags to Manage Access

Tags and tag namespace concepts:

Tags and Tag Namespace Concepts

Step 6: Create an optional ImageAdmin group

Many organizations separate VM launch permissions from image administration permissions.

Example group: ImageAdmin

Members of this group can be responsible for:

• Creating custom images
• Importing images
• Copying images across regions
• Applying defined tags
• Marking images as active or retired
• Deleting obsolete images
• Testing new image versions
• Maintaining image documentation

The ImageAdmin group should have permissions only in the approved image compartment and any supporting build compartments required by the image pipeline.

Managing custom images:

Managing Custom Images

Step 7: Validate the control with launch scenarios

Before treating this model as a compliance control, validate the expected behavior with several launch scenarios.

Recommended test cases:

The most important validation is whether users can launch from a public OCI platform image when their image read access is restricted to the approved image compartment or approved defined tags.

For a preventative governance model, the control must be enforced consistently at launch time across all access paths: Console, CLI, API, Terraform, and automation.

Creating an instance from a custom image:

Creating an Instance

Operational considerations

Managing custom images is not a one-time setup. It is an ongoing lifecycle process.

A mature image management process should include:

Image build process

Build images through a repeatable process instead of manual changes. The build process should install required agents, apply OS hardening, configure baseline logging, and validate that the image meets internal standards.

Image versioning

Use clear versioning so users and automation can distinguish between current, older, and retired images.

Example:

gold-rhel9-x86-2026-05

gold-rhel9-x86-2026-06

gold-rhel9-x86-2026-07

Image tagging

Apply defined tags to represent approval status, lifecycle state, OS family, owner, and release version.

Example lifecycle states:

candidate

active

deprecated

retired

Image retirement

Do not allow old images to remain active indefinitely. Retire images after the approved support window ends, and remove or update approval tags so they can no longer be used for new launches.

Region strategy

If images are needed in multiple regions, define a process to copy, validate, tag, and activate images consistently in each region.

Auditability

Track who created, updated, tagged, activated, deprecated, or deleted custom images. Image lifecycle changes should be auditable because they directly affect the compliance posture of new Compute instances.

Example end-to-end flow

A typical custom image lifecycle may look like this:

This approach provides a practical balance between platform control and user self-service.

Security guardrails and cautions

The effectiveness of this model depends heavily on IAM hygiene.

Avoid giving launcher users broad policies such as:

Allow group VMLaunchers to manage all-resources in tenancy

or broad image access such as:

Allow group VMLaunchers to read instance-images in tenancy

unless the access is constrained by defined tags or other approved conditions.

Also review inherited permissions from parent compartments and tenancy-level policies. A user may belong to multiple groups, and another broad grant may unintentionally allow access outside the approved image model.

For compliance-sensitive environments, policy design should be tested with real users and automation identities, not only reviewed on paper.

Long-term enhancement: Native allowed image controls

The compartment and tag-based model can help reduce risk and provide a practical operating pattern. However, many enterprises also need a native, declarative, preventative control that explicitly defines which images are allowed for Compute instance creation.

Comparable patterns exist in other cloud providers, such as AWS EC2 Allowed AMIs and Azure Policy with Azure Compute Gallery. The ideal long-term capability would allow administrators to centrally define approved image criteria and enforce them at instance launch time.

Useful criteria could include:

• Approved custom image compartment
• Approved image OCIDs
• Defined tag values
• Image lifecycle status
• Approved image catalog or gallery
• OS family or version
• Publisher or source
• Region-specific image approval state

The key requirement is preventative enforcement before the instance is created, rather than reactive detection and remediation after launch.

Conclusion

Custom image management is a foundational part of secure cloud operations. For enterprises that require hardened and compliant server baselines, approved gold images help ensure that every Compute instance starts from a trusted configuration.

On OCI, a practical approach is to separate VM deployment from image administration, store approved custom images in a dedicated compartment, grant launcher users only the permissions needed to create instances and read approved images, and use defined tags to manage image lifecycle state at scale.

This model can help organizations reduce configuration drift, improve auditability, and simplify compliance operations. However, it should be validated carefully to confirm that non-approved image sources are blocked consistently across Console, CLI, API, Terraform, and automation workflows.

By combining custom image lifecycle management, least-privilege IAM policies, defined tags, and clear operational ownership, enterprises can build a scalable gold image governance model for OCI Compute.