5.2 Construct Images

Go to 5. Operational Concept

Crucible constructs identified and version-controlled Images from controlled inputs.

Supported image forms include:

• Machine Images used to create virtual machines
• Container Images used to create containerized workloads

Image construction uses the applicable Baseline Composition, selected Image Layers, configuration, software packages, dependencies, security content, and other Controlled Inputs required by the selected image build.

The image build identifies the inputs required to construct the intended Image.

These inputs can include:

• A base Image
• Selected Image Layers
• Operating-system content
• Software packages
• Application content
• Configuration definitions
• Security configuration
• Compliance content
• Build tools
• Build dependencies
• Image metadata
• Applicable build parameters
• The applicable Crucible Description

Each controlled input retains its identity and revision so the resulting Image can be related to the content used to construct it.

Crucible constructs Machine Images used to create virtual machines.

A Machine Image build applies the selected Image Layers and other Controlled Inputs to the applicable base Image or image-building environment.

The resulting Machine Image has an identifiable representation that can be stored, retrieved, assessed, signed, verified, promoted, transferred, and deployed according to the applicable lifecycle requirements.

Machine Image construction does not itself authorize deployment. Separate requirements govern Image verification, promotion, deployment, and operational approval.

Crucible constructs Container Images used to create containerized workloads.

A Container Image build applies the selected Image Layers, application content, configuration, packages, and other Controlled Inputs required by the applicable build.

The resulting Container Image has an identifiable representation that can be stored, retrieved, assessed, signed, verified, promoted, transferred, and deployed according to the applicable lifecycle requirements.

Container Image construction does not require the same image format, build mechanism, or runtime used for Machine Images.

When a required change affects a deployed Image, Crucible constructs a new Image rather than modifying the existing deployed Image in place.

The newly constructed Image incorporates the required changes and receives its own identifiable revision.

An immutable image workflow preserves the relationship among:

• The existing deployed Image
• The required change
• The Controlled Inputs used to construct the replacement Image
• The newly constructed Image
• The replacement operation
• The resulting deployed state

The workflow does not prohibit changes to persistent data, credentials, network resources, or other state maintained separately from the Image.

Crucible signs an identified Image according to the applicable signing conditions.

The signing activity associates a Digital Signature with the identified Image.

The resulting record identifies:

• The signed Image
• The Image identifier and revision
• The Image content digest
• The signing identity
• The applicable signing conditions
• The Digital Signature
• The signing result

Image signing provides integrity and authenticity information but does not independently establish compliance, approval, promotion, or authorization for deployment.

Crucible verifies the Digital Signature associated with an identified Image.

Image verification determines whether the evaluated signature remains valid for the identified Image under the applicable verification conditions.

The verification activity records:

• The evaluated Image
• The Image identifier and revision
• The evaluated Digital Signature
• The applicable verification conditions
• The verification result
• The resulting Evidence

A valid Digital Signature does not independently establish that the Image:

• Is free from vulnerabilities
• Satisfies a Compliance Baseline
• Is approved for promotion
• Is authorized for deployment
• Is compatible with a Deployment Target
• Is suitable for a specified purpose

Separate requirements govern those determinations.

Crucible can promote an identified Image from one defined promotion state to another after the Image satisfies the applicable transition criteria.

The applicable promotion workflow defines:

• The promotion states
• The permitted state transitions
• The transition criteria
• The Evidence required for each transition
• The resulting promotion record

Promotion states can represent lifecycle conditions such as construction, evaluation, signing, verification, approval, release, availability for deployment, or retirement. The applicable workflow determines which states and transitions apply.

Image promotion does not independently define the assessments, approvals, or other conditions used as transition criteria. The applicable requirements, policies, and promotion workflow define those conditions.

The image-construction result records:

• The Image identifier
• The Image revision
• The Image form
• The selected Baseline Composition
• The selected Image Layers
• The Controlled Inputs
• The build operation
• The build result
• The Image content digest
• The associated Digital Signature, when produced
• The signature-verification result, when performed
• The promotion state, when applicable
• The associated Provenance
• The associated Traceability
• The generated Evidence

The constructed Image becomes a controlled input to subsequent assessment, transfer, deployment, validation, replacement, or retirement activities.

The linked leaf requirement pages remain the canonical sources.