Skip to main content

Image Templates

An Image Template is the central configuration entity in Klarity ImageFactory. It acts as a blueprint that defines how a golden image should be built, tested, and distributed. By creating a template, you establish a repeatable process for generating secure and compliant machine images across different cloud providers.

Templates encapsulate everything from the base operating system to the specific scripts and configurations required for your organization's infrastructure.

Template Properties​

Every template includes a set of core attributes that define its identity and behavior.

  • Name: A unique name for the template. It must follow specific validation rules, typically allowing alphanumeric characters, hyphens, and underscores.
  • Provider: The cloud platform for which the image is being built.
  • Distribution ID: The identifier of the source distribution used as the base.
  • Description: A clear explanation of the template's purpose.
  • OS Family: The operating system family (e.g., RHEL, Ubuntu, Windows).
  • State: The current status of the template (e.g., TEMPLATE_CREATED, TEMPLATE_PENDING).
  • Rebuild: Configuration for automated rebuilds.

Template Configuration​

The config object within a template contains the detailed instructions for the build process.

General Configuration​

  • Build Components: A list of components to be applied during the image creation phase.
  • Test Components: A list of components used to verify the image after it has been built.
  • Tags: Key-value pairs applied to the resulting image in the cloud provider's console.
  • Notifications: Settings for alerting users about build successes or failures.
  • Scope: Either PUBLIC or CHINA, determining the target environment.
  • Disable Cyclical Rebuilds: A flag to prevent the template from rebuilding automatically on a schedule.
  • Image Retain Count: The number of previous image versions to keep before older ones are deleted.
  • Cloud Account IDs: A list of accounts where the final image should be distributed.

Provider-Specific Configuration​

Each cloud provider has unique requirements that are handled through specialized configuration fields.

AWS​

  • Region: The primary AWS region for the build.
  • Custom Image Name: An optional override for the resulting AMI name.
  • EBS Volume Type: Support for gp2 or gp3 volumes.
  • Additional EBS Volumes: Configuration for extra data disks.
  • KMS Key ID: The identifier for the key used to encrypt the AMI.

Azure​

  • Replica Regions: A list of regions where the image should be replicated within the Shared Image Gallery.
  • Exclude From Latest: Prevents this version from being marked as the latest in the gallery.
  • VM Image Definition: The specific definition within the gallery.
  • EOL Date Option: Settings for managing the end-of-life date of the Azure image.
  • Trusted Launch: Enables features like Secure Boot and vTPM.
  • Additional Signatures: Support for UEFI keys and other security signatures.
  • Create Managed Image: An option to create a standalone managed image in addition to the gallery version.

GCP​

  • Custom Image Name: Supports timestamps to ensure unique image names for every build.

VMware​

  • Builder: Specifies whether to use the VCD (vCloud Director) or ESXi builder engine.

Template Components​

Components are added to templates using their unique ID and a version string. You can specify a fixed version or use the latest keyword to always include the most recent version of a component. Some components also accept properties, which are name-value pairs used to parameterize the scripts.

Build Statuses​

As a template moves through the build process, its state changes to reflect the current activity.

  • TEMPLATE_CREATED: The template has been defined but no build has started.
  • TEMPLATE_PENDING: A build has been triggered and is waiting for resources.
  • IMAGE_QUEUED: The build task is in the execution queue.
  • IMAGE_BUILDING: The temporary instance is being configured and the image captured.
  • IMAGE_TESTING: The captured image is being verified using test components.
  • IMAGE_CREATED: The build and test phases succeeded, and the image is ready.
  • IMAGE_ERROR: An error occurred during the build or test phase.
  • TEMPLATE_ERROR: A configuration error was detected before the build could start.

Automated Rebuild Reasons​

ImageFactory can automatically trigger a new build for several reasons, ensuring your images remain secure and up to date.

  1. SOURCE_IMAGE_CHANGE: A new version of the base distribution was detected in the cloud marketplace.
  2. SECURITY_CHECK: A vulnerability scan identified a need for updated patches.
  3. HARDENING_SCRIPT_CHANGE: A system component used for security hardening was updated.
  4. WEEKLY_UPDATES: A scheduled rebuild to ensure the latest OS updates are applied.
  5. MANUAL: A user manually triggered the build process.

By using these automated triggers, organizations can maintain a continuous delivery pipeline for their golden images, reducing the window of exposure to new vulnerabilities.