Jump to section

What is a golden image?

Copy URL

In media production, a gold image is the final cut of an album or film after all edits and mixing have been completed. It’s in its final, perfect form–it’s gold.

This meaning carried over into systems administration. In this context, a golden image is an intentionally configured snapshot of a system, (server, virtual desktop environment, or even a disk drive) which can be used to deploy new instances. Because this golden image (or sometimes gold image) is used in network virtualization to create new systems, it is also called a master image or clone image. Another popular term is a baseline image, which can be an illustrative term to frame why golden images are so useful: they create a consistent, reliable baseline for system configuration, which can make it easier to maintain those systems across their life cycle.

The concept of golden images starts with virtual machines, which themselves are specially configured and launched from templates. With virtual environments, golden images offer two key benefits: convenience and consistency. Using a predefined template image allows administrators to deploy systems consistently with clear and known configuration.

Cloud computing is essentially virtual environments at a massive scale; the underlying concepts and technologies are very similar, and the differences come down to hardware management and user experience. The main difference with cloud computing is volume–instances can be deployed, changed, or removed quickly and without restraints from resource consumption or access.

With cloud computing, golden images are valuable IT management tools, with the ability to scale by allowing admins to deploy large numbers of instances very quickly while maintaining consistency.

Cloud computing adds complexity to infrastructures; consistency across your systems (really, standard operating environments, otherwise known as an SOE) allows administrators to perform common admin tasks at scale, like patching systems, upgrading packages, even granting user access to required services.

The reasons to use golden images in your environment hit every stage of your system life cycle.

  • Faster deployment. Using golden images help you to deploy faster in cloud environments, both through scripting and automation or in ad hoc instances.
  • Reduced human error. According to the IBM Cyber Security Intelligence Index, 95% of breaches are caused by human error such as misconfigurations, unpatched systems, or poor access controls. Having a predefined and tested template reduces the risk of human error causing a vulnerable system.
  • Faster patch management and upgrades. Having defined templates helps with visibility and monitoring because it is possible to see quickly what systems require a patch or an updated package, or which ones are affected by a security vulnerability. It also allows for effective use of automation, rather than having to update each system individually and risking missing or misconfiguring systems.
  • Maintaining configuration. "Configuration drift" is a somewhat recognized term, but there is still a lot of confusion. Drift means that a system has changed from an ideal baseline, either through adding or modifying applications, changing security settings, or changing system configurations between the data center and recovery systems. Without a baseline, it can be very difficult to identify when or how systems have been modified–and this can be crucial to maintain compliance systems for regulatory and industry standards. Using a baseline means that you can monitor systems for drift (which you can do for Red Hat® Enterprise Linux® and Red Hat OpenShift® systems through Red Hat Insights).

Security is not a configuration setting, good security is a practice. It’s the cumulative effect of many different administrative and process choices. You can incorporate your specific security requirements and practices into your baseline images, which helps maintain your security posture even in different cloud environments and different footprints.

Unlike in media production, IT systems are never "done". Good IT practice requires maintaining the entire life cycle of systems, and with golden images, that requires maintaining both the image catalog and the systems deployed using the templates.

  • Have a separate virtual environment to create new images. When using a tool like Red Hat Enterprise Linux image builder to create a new base image, it is strongly encouraged to use a dedicated virtual machine because of the specific security requirements for the system. 
  • Consider setting up roles, groups, and services within your system configuration. One of the bottlenecks for cloud deployments isn’t deploying a new instance, it’s granting the right user and service access to new instances. Use the system security configuration to have required groups and roles done as part of the deployment process to make the overall authentication/authorization process more streamlined.
  • Test before you launch. Have a QA process in place to test that the configuration (especially around applications and security) meet your requirements. Test for performance–packages should be optimized for the specific cloud environment in which they’ll be used.
  • Update images when new packages are released. It’s easy to create new images or edit images using tools like image builder. To maintain the security and capabilities of the images, update the images as new versions of included packages are available.
  • Monitor your deployed systems. Services like Red Hat Insights give visibility over your entire infrastructure, and using a set of baseline images can make it easier to identify vulnerable systems, create playbooks for automation, and track drift within systems.
  • Have processes to retire images and systems. Create explicit policies for updating and deprecating images within your catalog and how to manage systems as images are changed and retired.
  • Make images for a specific purpose. Identify different profiles that you use within your environment, and create baseline images that are specific for those different purposes. There is no reason to have a one-size-fits-all image, and using more custom images can help attain requirements around performance or security.

If you want to build your own images, Red Hat Enterprise Linux has a tool called image builder, which can be run locally or through Red Hat Hybrid Cloud Console as a hosted service. Image builder breaks creating a custom image into a handful of simple steps, where you can select packages, set configuration, and then optimize the underlying operating system for a specific cloud environment.

Red Hat also has a program called Cloud Access, which allows organizations to use their subscription with public cloud providers. As part of the Cloud Access program, Red Hat has created certified, prebuilt images for Amazon Web Services (AWS), Microsoft Azure, and Google clouds for all of the major products from Red Hat, including Red Hat Enterprise Linux, middleware, and storage.

Red Hat even has optimized, OCI-compliant container images as part of its Universal Base Image Catalog.

Keep reading


Containers vs VMs

Linux containers and virtual machines (VMs) are packaged computing environments that combine various IT components and isolate them from the rest of the system.


What is a virtual machine (VM)?

A virtual machine (VM) is an isolated computing environment created by abstracting resources from a physical machine.


What is KVM?

Kernel-based virtual machines (KVM) are an open source virtualization technology that turns Linux into a hypervisor.

More about cloud computing


A platform that virtualizes hardware and organizes those resources into clouds.

An enterprise-ready Kubernetes container platform with full-stack automated operations to manage hybrid cloud, multicloud, and edge deployments.

Engagements with our strategic advisers who take a big-picture view of your organization, analyze your challenges, and help you overcome them with comprehensive, cost-effective solutions.



Free training course

Red Hat OpenStack Technical Overview