buildah-commit(1)

okay bestie, welcome to buildah-commit(1) from the General Commands Manual — the page that teaches you how to create an image from a working container, and it is lowkey iconic ✨

✨ NAME ✨

buildah-commit — create an image from a working container. That’s it, that’s the whole assignment 💅

🛠️ SYNOPSIS 🛠️

buildah commit [options] container [image]

💖 DESCRIPTION 💖

okay so here’s the tea: this command writes a new image using the specified container’s read-write layer, and if that container is based on an image, it also uses the layers of that image 🫶

About the image name: if it does not begin with a registry name component, localhost gets added to the name. If image is not provided at all, the image will have no name. And when an image has no name, the buildah images command will display <none> in the REPOSITORY and TAG columns — no cap 😭

The image value supports all transports from containers-transports(5). If no transport is specified, the containers-storage (i.e., local storage) transport is used. Slay.

🎁 RETURN VALUE 🎁

The image ID of the image that was created. On error, 1 is returned and errno is returned. periodt.

🌈 OPTIONS 🌈

• --add-file source[:destination] — read the contents of file source and add it to the committed image as a file at destination 💖. If destination is not specified, the path of source will be used. The new file will be owned by UID 0, GID 0, have 0644 permissions, and be given the timestamp specified to the --timestamp option if it is specified. This option can be specified multiple times.
• --annotation annotation[=value] — add an image annotation (e.g. annotation=value) to the image metadata. Can be used multiple times. If annotation is named, but neither = nor a value is provided, then the annotation is set to an empty value. Note: this information is not present in Docker image formats, so it is discarded when writing images in Docker formats.
• --authfile path — path of the authentication file. Default is ${XDG_RUNTIME_DIR}/containers/auth.json. See containers-auth.json(5) for more information. This file is created using buildah login. If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using docker login. Note: you can also override the default path of the authentication file by setting the REGISTRY_AUTH_FILE environment variable: export REGISTRY_AUTH_FILE=path.
• --cert-dir path — use certificates at path (*.crt, *.cert, *.key) to connect to the registry. The default certificates directory is /etc/containers/certs.d.
• --change, -c "INSTRUCTION" — apply the change to the committed image that would have been made if it had been built using a Containerfile which included the specified instruction. This option can be specified multiple times.
• --compression-format format — specifies the compression format to use. Supported values are: gzip, zstd and zstd:chunked. If not specified, the format is read from the compression_format setting in containers.conf. Cannot be used together with --disable-compression.
• --compression-level level — specifies the compression level to use. The value is specific to the compression algorithm used, e.g. for zstd the accepted values are in the range 1-20 (inclusive), while for gzip it is 1-9 (inclusive). If not specified, the level is read from the compression_level setting in containers.conf.
• --config filename — read a JSON-encoded version of an image configuration object from the specified file, and merge the values from it with the configuration of the image being committed.
• --created-annotation — add an image annotation (see also --annotation) to the image metadata setting "org.opencontainers.image.created" to the current time, or to the datestamp specified to the --source-date-epoch or --timestamp flag, if either was used. If false, no such annotation will be present in the written image. Note: this information is not present in Docker image formats, so it is discarded when writing images in Docker formats.
• --creds creds — the [username[:password]] to use to authenticate with the registry if required. If one or both values are not supplied, a command line prompt will appear and the value can be entered. The password is entered without echo.
• --cw options — produce an image suitable for use as a confidential workload running in a trusted execution environment (TEE) using krun (i.e., crun built with the libkrun feature enabled and invoked as krun). Instead of the conventional contents, the root filesystem of the image will contain an encrypted disk image and configuration information for krun.

The value for options is a comma-separated list of key=value pairs, supplying configuration information which is needed for producing the additional data which will be included in the container image. Recognized keys are:

• attestation_url: the location of a key broker / attestation server. If a value is specified, the new image’s workload ID, along with the passphrase used to encrypt the disk image, will be registered with the server, and the server’s location will be stored in the container image. At run-time, krun is expected to contact the server to retrieve the passphrase using the workload ID, which is also stored in the container image. If no value is specified, a passphrase value must be specified.
• cpus: the number of virtual CPUs which the image expects to be run with at run-time. If not specified, a default value will be supplied.
• firmware_library: the location of the libkrunfw-sev shared library. If not specified, buildah checks for its presence in a number of hard-coded locations.
• memory: the amount of memory which the image expects to be run with at run-time, as a number of megabytes. If not specified, a default value will be supplied.
• passphrase: the passphrase to use to encrypt the disk image which will be included in the container image. If no value is specified, but an attestation_url value is specified, a randomly-generated passphrase will be used. The authors recommend setting an attestation_url but not a passphrase.
• slop: extra space to allocate for the disk image compared to the size of the container image’s contents, expressed either as a percentage (..%) or a size value (bytes, or larger units if suffixes like KB or MB are present), or a sum of two or more such specifications separated by +. If not specified, buildah guesses that 25% more space than the contents will be enough, but this option is provided in case its guess is wrong. If the specified or computed size is less than 10 megabytes, it will be increased to 10 megabytes.
• type: the type of trusted execution environment (TEE) which the image should be marked for use with. Accepted values are "SEV" (AMD Secure Encrypted Virtualization - Encrypted State) and "SNP" (AMD Secure Encrypted Virtualization - Secure Nested Paging). If not specified, defaults to "SNP".
• workload_id: a workload identifier which will be recorded in the container image, to be used at run-time for retrieving the passphrase which was used to encrypt the disk image. If not specified, a semi-random value will be derived from the base image’s image ID.

• --disable-compression, -D — don’t compress filesystem layers when building the image unless it is required by the location where the image is being written. This is the default setting, because image layers are compressed automatically when they are pushed to registries, and images being written to local storage would only need to be decompressed again to be stored. Compression can be forced in all cases by specifying --disable-compression=false. Cannot be used together with --compression-format or --force-compression.
• --encrypt-layer layer(s) — layer(s) to encrypt: 0-indexed layer indices with support for negative indexing (e.g. 0 is the first layer, -1 is the last layer). If not defined, will encrypt all layers if the encryption-key flag is specified.
• --encryption-key key — the [protocol:keyfile] specifies the encryption protocol, which can be JWE (RFC7516), PGP (RFC4880), and PKCS7 (RFC2315) and the key material required for image encryption. For instance, jwe:/path/to/key.pem or pgp:admin@example.com or pkcs7:/path/to/x509-file.
• --force-compression — if set, commit uses the specified compression algorithm even if the destination contains a differently-compressed variant already. Defaults to true if --compression-format is explicitly specified on the command-line or compression_format is set in containers.conf, false otherwise.
• --format, -f [oci | docker] — control the format for the image manifest and configuration data. Recognized formats include oci (OCI image-spec v1.0, the default) and docker (version 2, using schema format 2 for the manifest). Note: you can also override the default format by setting the BUILDAH_FORMAT environment variable: export BUILDAH_FORMAT=docker.
• --identity-label bool-value — adds a label io.buildah.version with its value set to the version of buildah which committed the image (default true unless --timestamp or --source-date-epoch is used).
• --iidfile ImageIDfile — write the image ID to the file.
• --manifest "listName" — name of the manifest list to which the built image will be added. Creates the manifest list if it does not exist. This option is useful for building multi architecture images.
• --metadata-file MetadataFile — write information about the committed image to the named file.
• --omit-history bool-value — omit build history information in the built image (default false). This option is useful for the cases where end users explicitly want to set --omit-history to omit the optional History from built images or when working with images built using build tools that do not include History information in their images.
• --pull — when the --pull flag is enabled or set explicitly to true (with --pull=true), attempt to pull the latest versions of SBOM scanner images from the registries listed in registries.conf if a local SBOM scanner image does not exist or the image in the registry is newer than the one in local storage. Raise an error if the SBOM scanner image is not in any listed registry and is not present locally.
  • If the flag is disabled (with --pull=false), do not pull SBOM scanner images from registries, use only local versions. Raise an error if a SBOM scanner image is not present locally.
  • If the pull flag is set to always (with --pull=always), pull SBOM scanner images from the registries listed in registries.conf. Raise an error if a SBOM scanner image is not found in the registries, even if an image with the same name is present locally.
  • If the pull flag is set to missing (with --pull=missing), pull SBOM scanner images only if they could not be found in the local containers storage. Raise an error if no image could be found and the pull fails.

Okay so if the pull flag is set to never (with --pull=never), do not pull SBOM scanner images from registries — use only the local versions. If the image isn't present locally, it raises an error. Like, no cap, it's not gonna go fetch it for you. 🙅‍♀️

• --quiet, -q — when writing the output image, suppress the progress output. Silence is golden, bestie.
• --rewrite-timestamp — when generating the new layer for the image, make sure no newly added content bears a timestamp later than the value used by the --source-date-epoch flag, if one was provided — by replacing any timestamps that are later than that value with that value. Time crime = corrected. ⏰
• --rm — remove the working container and its contents after creating the image. The default leaves the container and its content in place. (So if you don't pass this, your container is still chilling there afterwards 💀)
• --sbom preset — generate SBOMs (Software Bills Of Materials) for the output image by scanning the working container and build contexts, using the named combination of scanner image, scanner commands, and merge strategy. Must be specified with one or more of --sbom-image-output, --sbom-image-purl-output, --sbom-output, and --sbom-purl-output. Recognized presets, and the set of options which they equate to:
  • "syft", "syft-cyclonedx":

--sbom-scanner-image=ghcr.io/anchore/syft
--sbom-scanner-command="/syft scan -q dir:{ROOTFS} --output cyclonedx-json={OUTPUT}"
--sbom-scanner-command="/syft scan -q dir:{CONTEXT} --output cyclonedx-json={OUTPUT}"
--sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version

• "syft-spdx":

--sbom-scanner-image=ghcr.io/anchore/syft
--sbom-scanner-command="/syft scan -q dir:{ROOTFS} --output spdx-json={OUTPUT}"
--sbom-scanner-command="/syft scan -q dir:{CONTEXT} --output spdx-json={OUTPUT}"
--sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo

• "trivy", "trivy-cyclonedx":

--sbom-scanner-image=ghcr.io/aquasecurity/trivy
--sbom-scanner-command="trivy filesystem -q {ROOTFS} --format cyclonedx --output {OUTPUT}"
--sbom-scanner-command="trivy filesystem -q {CONTEXT} --format cyclonedx --output {OUTPUT}"
--sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version

• "trivy-spdx":

--sbom-scanner-image=ghcr.io/aquasecurity/trivy
--sbom-scanner-command="trivy filesystem -q {ROOTFS} --format spdx-json --output {OUTPUT}"
--sbom-scanner-command="trivy filesystem -q {CONTEXT} --format spdx-json --output {OUTPUT}"
--sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo

• --sbom-image-output path — when generating SBOMs, store the generated SBOM in the specified path in the output image. There is no default. ✨
• --sbom-image-purl-output path — when generating SBOMs, scan them for PURL (package URL) information, and save a list of found PURLs to the named file in the local filesystem. There is no default. (The package URL spec lives at https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst, iykyk 🫶)
• --sbom-merge-strategy method — if more than one --sbom-scanner-command value is being used, use the specified method to merge the output from later commands with output from earlier commands. Recognized values include:
  • cat — concatenate the files.
  • merge-cyclonedx-by-component-name-and-version — merge the "component" fields of JSON documents, ignoring values from documents when the combination of their "name" and "version" values is already present. Documents are processed in the order in which they are generated, which is the order in which the commands that generate them were specified.
  • merge-spdx-by-package-name-and-versioninfo — merge the "package" fields of JSON documents, ignoring values from documents when the combination of their "name" and "versionInfo" values is already present. Documents are processed in the order in which they are generated, which is the order in which the commands that generate them were specified.
• --sbom-output file — when generating SBOMs, store the generated SBOM in the named file on the local filesystem. There is no default. 🌸
• --sbom-purl-output file — when generating SBOMs, scan them for PURL (package URL) information, and save a list of found PURLs to the named file in the local filesystem. There is no default. (Same spec link as above: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst — go read it, it's giving documentation 💅)
• --sbom-scanner-command image — generate SBOMs by running the specified command from the scanner image. If multiple commands are specified, they are run in the order in which they are specified. These text substitutions are performed:
  • {ROOTFS} — the root of the built image's filesystem, bind mounted.
  • {CONTEXT} — the build context and additional build contexts, bind mounted.
  • {OUTPUT} — the name of a temporary output file, to be read and merged with others or copied elsewhere.
• --sbom-scanner-image image — generate SBOMs using the specified scanner image. 🧚
• --sign-by fingerprint — sign the new image using the GPG key that matches the specified fingerprint. Signature slay. ✍️
• --source-date-epoch seconds — set the "created" timestamp for the image to this number of seconds since the epoch (Unix time 0, i.e., 00:00:00 UTC on 1 January 1970) to make it easier to create deterministic builds (defaults to $SOURCE_DATE_EPOCH if set, otherwise the current time will be used).

The "created" timestamp is written into the image's configuration and manifest when the image is committed, so committing the same working container at two different times will produce images with different sha256 hashes, even if no other changes were made to the working container in between. 😭 (yes, really, the hash changes just from time passing)

When --source-date-epoch is set, the "created" timestamp is always set to the time specified, which should allow for identical images to be committed at different times.

Conflicts with the similar --timestamp flag, which also sets its specified time on layer contents. ⚠️

• --squash — squash all of the new image's layers (including those inherited from a base image) into a single new layer. Flatten it, periodt. 🫂
• --timestamp seconds — set the "created" timestamp for the image to this number of seconds since the epoch (Unix time 0, i.e., 00:00:00 UTC on 1 January 1970) to make it easier to create deterministic builds (defaults to current time).

The "created" timestamp is written into the image's configuration and manifest when the image is committed, so committing the same working container at two different times will produce images with different sha256 hashes, even if no other changes were made to the working container in between.

When --timestamp is set, the "created" timestamp is always set to the time specified, which should allow for identical images to be committed at different times. All content in the new layer added as part of the image will also bear this timestamp.

Conflicts with the similar --source-date-epoch flag, which by default does not affect the timestamps of layer contents. ⚠️

• --tls-verify bool-value — require HTTPS and verification of certificates when talking to container registries (defaults to true). TLS verification cannot be used when talking to an insecure registry. 🔒
• --unsetannotation annotation — unset the image annotation, causing the annotation not to be inherited from the base image. Bye bye annotation 👋
• --unsetenv env — unset environment variables from the final image.

---

🎀 EXAMPLE 🎀

This example saves an image based on the container:

buildah commit containerID newImageName

This example saves an image named newImageName based on the container and removes the working container:

buildah commit --rm containerID newImageName

This example commits to an OCI archive file named /tmp/newImageName based on the container:

buildah commit containerID oci-archive:/tmp/newImageName

This example saves an image with no name, removes the working container, and creates a new container using the image's ID:

buildah from $(buildah commit --rm containerID)

This example saves an image based on the container disabling compression:

buildah commit --disable-compression containerID

This example saves an image named newImageName based on the container disabling compression:

buildah commit --disable-compression containerID newImageName

This example commits the container to the image on the local registry while turning off tls verification:

buildah commit --tls-verify=false containerID docker://localhost:5000/imageId

This example commits the container to the image on the local registry using credentials and certificates for authentication:

buildah commit --cert-dir ~/auth  --tls-verify=true --creds=username:password containerID docker://localhost:5000/imageId

This example commits the container to the image on the local registry using credentials from the /tmp/auths/myauths.json file and certificates for authentication:

buildah commit --authfile /tmp/auths/myauths.json --cert-dir ~/auth --tls-verify=true --creds=username:password containerID docker://localhost:5000/imageName

This example saves an image based on the container, but stores dates based on epoch time:

buildah commit --timestamp=0 containerID newImageName

Building an multi-architecture image using the --manifest option (requires emulation software)

#!/bin/sh
build() {
     ctr=$(./bin/buildah from --arch $1 ubi8)
     ./bin/buildah run $ctr dnf install -y iputils
     ./bin/buildah commit --manifest ubi8ping $ctr
}
build arm
build amd64
build s390x

---

🌈 ENVIRONMENT 🌈

BUILD_REGISTRY_SOURCES

BUILD_REGISTRY_SOURCES, if set, is treated as a JSON object which contains lists of registry names under the keys insecureRegistries, blockedRegistries, and allowedRegistries. 👑

When committing an image, if the image is to be given a name, the portion of the name that corresponds to a registry is compared to the items in the blockedRegistries list, and if it matches any of them, the commit attempt is denied. If there are registries in the allowedRegistries list, and the portion of the name that corresponds to the registry is not in the list, the commit attempt is denied. Like, denied denied. 🚫

TMPDIR — the TMPDIR environment variable allows the user to specify where temporary files are stored while pulling and pushing images. Defaults to /var/tmp. 🗂️

🎀 FILES 🎀

Okay bestie, these are the config files doing the behind-the-scenes work. Lowkey obsessed with how much power they hold 💅

• /etc/containers/registries.conf (that's registries.conf) — this is the config file that says which container registries should be consulted when it's completing image names that don't already include a registry or domain portion. Like, if you're being vague about where an image lives, this file is the one that fills in the blanks 🦋
• /etc/containers/policy.json (yup, policy.json) — the signature policy file, and she's kind of a big deal 👑 This defines the trust policy for container images. It controls which container registries can be used for an image, and whether or not the tool should trust the images. So basically it's the vibe check for trust ✨

---

🌈 SEE ALSO 🌈

Go read these next, fr fr — your girl does not gatekeep 📚

• buildah(1)
• buildah-images(1)
• containers-policy.json(5)
• containers-registries.conf(5)
• containers-transports(5)
• containers-auth.json(5)

---

and that's the whole page, bestie!! 🫶 You just read the buildah manual for buildah-commit(1) — dated March 2017, from the buildah source 💖 Go forth and commit your containers, you absolute icon ⭐💅