@ -9,7 +9,7 @@ Containerfile(Dockerfile) - automate the steps of creating a container image
The **Containerfile** is a configuration file that automates the steps of creating a container image. It is similar to a Makefile. Container engines (Podman, Buildah, Docker) read instructions from the **Containerfile** to automate the steps otherwise performed manually to create an image. To build an image, create a file called **Containerfile**.
The **Containerfile** is a configuration file that automates the steps of creating a container image. It is similar to a Makefile. Container engines (Podman, Buildah, Docker) read instructions from the **Containerfile** to automate the steps otherwise performed manually to create an image. To build an image, create a file called **Containerfile**.
The **Containerfile** describes the steps taken to assemble the image. When the
The **Containerfile** describes the steps taken to assemble the image. When the
**Containerfile** has been created, call the `buildah bud`, `podman build`, `docker build` command,
**Containerfile** has been created, call the `buildah build`, `podman build`, `docker build` command,
using the path of context directory that contains **Containerfile** as the argument. Podman and Buildah default to **Containerfile** and will fall back to **Dockerfile**. Docker only will search for **Dockerfile** in the context directory.
using the path of context directory that contains **Containerfile** as the argument. Podman and Buildah default to **Containerfile** and will fall back to **Dockerfile**. Docker only will search for **Dockerfile** in the context directory.
@ -31,7 +31,7 @@ A Containerfile is similar to a Makefile.
# USAGE
# USAGE
```
```
buildah bud .
buildah build .
podman build .
podman build .
```
```
@ -40,7 +40,7 @@ A Containerfile is similar to a Makefile.
build.
build.
```
```
buildah bud -t repository/tag .
buildah build -t repository/tag .
podman build -t repository/tag .
podman build -t repository/tag .
```
```
@ -49,19 +49,19 @@ A Containerfile is similar to a Makefile.
to a new image if necessary, before finally outputting the ID of the new
to a new image if necessary, before finally outputting the ID of the new
image.
image.
Container engines re-use intermediate images whenever possible. This significantly
Container engines reuse intermediate images whenever possible. This significantly
accelerates the *build* process.
accelerates the *build* process.
# FORMAT
# FORMAT
`FROM image`
`FROM image [AS <name>]`
`FROM image:tag`
`FROM image:tag [AS <name>]`
`FROM image@digest`
`FROM image@digest [AS <name>]`
-- The **FROM** instruction sets the base image for subsequent instructions. A
-- The **FROM** instruction sets the base image for subsequent instructions. A
valid Containerfile must have either **ARG** or *FROM** as its first instruction.
valid Containerfile must have either **ARG** or **FROM** as its first instruction.
If **FROM** is not the first instruction in the file, it may only be preceded by
If **FROM** is not the first instruction in the file, it may only be preceded by
one or more ARG instructions, which declare arguments that are used in the next FROM line in the Containerfile.
one or more ARG instructions, which declare arguments that are used in the next FROM line in the Containerfile.
The image can be any valid image. It is easy to start by pulling an image from the public
The image can be any valid image. It is easy to start by pulling an image from the public
@ -82,6 +82,9 @@ A Containerfile is similar to a Makefile.
-- If no digest is given to the **FROM** instruction, container engines apply the
-- If no digest is given to the **FROM** instruction, container engines apply the
`latest` tag. If the used tag does not exist, an error is returned.
`latest` tag. If the used tag does not exist, an error is returned.
-- A name can be assigned to a build stage by adding **AS name** to the instruction.
The name can be referenced later in the Containerfile using the **FROM** or **COPY --from=<name>** instructions.
**MAINTAINER**
**MAINTAINER**
-- **MAINTAINER** sets the Author field for the generated images.
-- **MAINTAINER** sets the Author field for the generated images.
Useful for providing users with an email or url for support.
Useful for providing users with an email or url for support.
@ -106,7 +109,7 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
@ -128,6 +131,18 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
· from: stage or image name for the root of the source. Defaults to the build context.
· from: stage or image name for the root of the source. Defaults to the build context.
· relabel=shared, z: Relabels src content with a shared label.
. relabel=private, Z: Relabels src content with a private label.
Labeling systems like SELinux require proper labels on the bind mounted content mounted into a container. Without a label, the security system might prevent the processes running in side the container from using the content. By default, container engines do not change the labels set by the OS. The relabel flag tells the engine to relabel file objects on the shared mountz.
The relabel=shared and z options tell the engine that two or more containers will share the mount content. The engine labels the content with a shared content label.
The relabel=private and Z options tell the engine to label the content with a private unshared label. Only the current container can use a private mount.
Relabeling walks the file system under the mount and changes the label on each file, if the mount has thousands of inodes, this process takes a long time, delaying the start of the container.
· rw, read-write: allows writes on the mount.
· rw, read-write: allows writes on the mount.
Options specific to tmpfs:
Options specific to tmpfs:
@ -154,6 +169,47 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
· rw, read-write: allows writes on the mount.
· rw, read-write: allows writes on the mount.
**RUN --network**
`RUN --network` allows control over which networking environment the command
- `id` is the identifier for the secret passed into the `buildah bud --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
- `id` is the identifier for the secret passed into the `buildah build --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
- `dst`|`target`|`destination` rename the secret file to a specific file in the Containerfile RUN command to use.
- `dst`|`target`|`destination` rename the secret file to a specific file in the Containerfile RUN command to use.
@ -180,7 +236,7 @@ RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
The secret needs to be passed to the build using the --secret flag. The final image built does not container the secret file:
The secret needs to be passed to the build using the --secret flag. The final image built does not container the secret file:
@ -5,30 +5,33 @@ containers-auth.json - syntax for the registry authentication file
# DESCRIPTION
# DESCRIPTION
A credentials file in JSON format used to authenticate against container image registries.
A file in JSON format controlling authentication against container image registries.
The primary (read/write) file is stored at `${XDG_RUNTIME_DIR}/containers/auth.json` on Linux;
The primary (read/write) file is stored at `${XDG_RUNTIME_DIR}/containers/auth.json` on Linux;
on Windows and macOS, at `$HOME/.config/containers/auth.json`.
on Windows and macOS, at `$HOME/.config/containers/auth.json`.
When searching for the credential for a registry, the following files will be read in sequence until the valid credential is found:
When searching for the credential for a registry, the following files will be read in sequence until the valid credential is found:
first reading the primary (read/write) file, or the explicit override using an option of the calling application.
first reading the primary (read/write) file, or the explicit override using an option of the calling application.
If credentials are not present, search in `${XDG_CONFIG_HOME}/containers/auth.json` (usually `~/.config/containers/auth.json`), `$HOME/.docker/config.json`, `$HOME/.dockercfg`.
If credentials are not present there,
the search continues in `${XDG_CONFIG_HOME}/containers/auth.json` (usually `~/.config/containers/auth.json`), `$HOME/.docker/config.json`, `$HOME/.dockercfg`.
Except the primary (read/write) file, other files are read-only, unless the user use an option of the calling application explicitly points at it as an override.
Except for the primary (read/write) file, other files are read-only unless the user, using an option of the calling application, explicitly points at it as an override.
## FORMAT
## FORMAT
The auth.json file stores encrypted authentication information for the
The auth.json file stores, or references, credentials that allow the user to authenticate
user to container image registries. The file can have zero to many entries and
to container image registries.
is created by a `login` command from a container tool such as `podman login`,
It is primarily managed by a `login` command from a container tool such as `podman login`,
`buildah login` or `skopeo login`. Each entry either contains a single
`buildah login`, or `skopeo login`.
hostname (e.g. `docker.io`) or a namespace (e.g. `quay.io/user/image`) as a key
and an auth token in the form of a base64 encoded string as value of `auth`. The
Each entry contains a single hostname (e.g., `docker.io`) or a namespace (e.g., `quay.io/user/image`) as a key,
token is built from the concatenation of the username, a colon, and the
and credentials in the form of a base64-encoded string as value of `auth`. The
password. The registry name can additionally contain a repository name (an image
base64-encoded string contains a concatenation of the username, a colon, and the
name without tag or digest) and namespaces. The path (or namespace) is matched
password.
in its hierarchical order when checking for available authentications. For
example, an image pull for `my-registry.local/namespace/user/image:latest` will
When checking for available credentials, the relevant repository is matched
against available keys in its hierarchical order, going from most-specific to least-specific.
For example, an image pull for `my-registry.local/namespace/user/image:latest` will
result in a lookup in `auth.json` in the following order:
result in a lookup in `auth.json` in the following order:
- `my-registry.local/namespace/user/image`
- `my-registry.local/namespace/user/image`
@ -77,10 +80,8 @@ preserving a fallback for `my-registry.local`:
An entry can be removed by using a `logout` command from a container
An entry can be removed by using a `logout` command from a container
tool such as `podman logout` or `buildah logout`.
tool such as `podman logout` or `buildah logout`.
In addition, credential helpers can be configured for specific registries and the credentials-helper
In addition, credential helpers can be configured for specific registries, and the credentials-helper
software can be used to manage the credentials in a more secure way than depending on the base64 encoded authentication
software can be used to manage the credentials more securely than storing only base64-encoded credentials in `auth.json`.
provided by `login`. If the credential helpers are configured for specific registries, the base64 encoded authentication will not be used
for operations concerning credentials of the specified registries.
When the credential helper is in use on a Linux platform, the auth.json file would contain keys that specify the registry domain, and values that specify the suffix of the program to use (i.e. everything after docker-credential-). For example:
When the credential helper is in use on a Linux platform, the auth.json file would contain keys that specify the registry domain, and values that specify the suffix of the program to use (i.e. everything after docker-credential-). For example:
@ -30,7 +30,9 @@ Policy requirements can be defined for:
Usually, a scope can be defined to match a single image, and various prefixes of
Usually, a scope can be defined to match a single image, and various prefixes of
such a most specific scope define namespaces of matching images.
such a most specific scope define namespaces of matching images.
- A default policy for a single transport, expressed using an empty string as a scope
- A default policy for a single transport, expressed using an empty string as a scope
- A global default policy.
- A global default policy.
If multiple policy requirements match a given image, only the requirements from the most specific match apply,
If multiple policy requirements match a given image, only the requirements from the most specific match apply,
@ -59,18 +61,41 @@ The global `default` set of policy requirements is mandatory; all of the other f
<!-- NOTE: Keep this in sync with transports/transports.go! -->
<!-- NOTE: Keep this in sync with transports/transports.go! -->
## Supported transports and their scopes
## Supported transports and their scopes
See containers-transports(5) for general documentation about the transports and their reference syntax.
### `atomic:`
### `atomic:`
The `atomic:` transport refers to images in an Atomic Registry.
The deprecated `atomic:` transport refers to images in an Atomic Registry.
Supported scopes use the form _hostname_[`:`_port_][`/`_namespace_[`/`_imagestream_ [`:`_tag_]]],
Supported scopes use the form _hostname_[`:`_port_][`/`_namespace_[`/`_imagestream_ [`:`_tag_]]],
i.e. either specifying a complete name of a tagged image, or prefix denoting
i.e. either specifying a complete name of a tagged image, or prefix denoting
a host/namespace/image stream or a wildcarded expression for matching all
a host/namespace/image stream, or a wildcarded expression starting with `*.` for matching all
subdomains. For wildcarded subdomain matching, `*.example.com` is a valid case, but `example*.*.com` is not.
subdomains. For wildcarded subdomain matching, `*.example.com` is a valid case, but `example*.*.com` is not.
*Note:* The _hostname_ and _port_ refer to the container registry host and port (the one used
*Note:* The _hostname_ and _port_ refer to the container registry host and port (the one used
e.g. for `docker pull`), _not_ to the OpenShift API host and port.
e.g. for `docker pull`), _not_ to the OpenShift API host and port.
### `containers-storage:`
Supported scopes have the form `[`_storage-specifier_`]`_image-scope_.
`[`_storage-specifier_`]` is usually `[`_graph-driver-name_`@`_graph-root_`]`, e.g. `[overlay@/var/lib/containers/storage]`.
_image-scope_ matching the individual image is
- a named Docker reference *in the fully expanded form*, either using a tag or digest. For example, `docker.io/library/busybox:latest` (*not* `busybox:latest`)
- and/or (depending on which one the user’s input provides) `@`_image-id_
More general scopes are prefixes of individual-image scopes, and specify a less-precisely-specified image, or a repository
(by omitting first the image ID, if any; then the digest, if any; and finally a tag, if any),
a repository namespace, or a registry host (by only specifying the host name and possibly a port number).
Finally, two full-store specifiers matching all images in the store are valid scopes:
- `[`_graph-driver-name_`@`_graph-root_`]` and
- `[`_graph-root_`]`
Note that some tools like Podman and Buildah hard-code overrides of the signature verification policy for “push” operations,
allowing these operations regardless of configuration in `policy.json`.
### `dir:`
### `dir:`
The `dir:` transport refers to images stored in local directories.
The `dir:` transport refers to images stored in local directories.
@ -78,9 +103,9 @@ The `dir:` transport refers to images stored in local directories.
Supported scopes are paths of directories (either containing a single image or
Supported scopes are paths of directories (either containing a single image or
subdirectories possibly containing images).
subdirectories possibly containing images).
*Note:* The paths must be absolute and contain no symlinks. Paths violating these requirements may be silently ignored.
*Note:*
- The paths must be absolute and contain no symlinks. Paths violating these requirements may be silently ignored.
The top-level scope `"/"` is forbidden; use the transport default scope `""`,
- The top-level scope `"/"` is forbidden; use the transport default scope `""`,
for consistency with other transports.
for consistency with other transports.
### `docker:`
### `docker:`
@ -91,24 +116,73 @@ Scopes matching individual images are named Docker references *in the fully expa
using a tag or digest. For example, `docker.io/library/busybox:latest` (*not* `busybox:latest`).
using a tag or digest. For example, `docker.io/library/busybox:latest` (*not* `busybox:latest`).
More general scopes are prefixes of individual-image scopes, and specify a repository (by omitting the tag or digest),
More general scopes are prefixes of individual-image scopes, and specify a repository (by omitting the tag or digest),
a repository namespace, or a registry host (by only specifying the host name)
a repository namespace, or a registry host (by only specifying the host name and possibly a port number)
or a wildcarded expression for matching all subdomains. For wildcarded subdomain
or a wildcarded expression starting with `*.`, for matching all subdomains (not including a port number). For wildcarded subdomain
matching, `*.example.com` is a valid case, but `example*.*.com` is not.
### `docker-archive:`
Only the default `""` scope is supported.
### `docker-daemon:`
For references using the _algo:digest_ format (referring to an image ID), only the default `""` scope is used.
For images using a named reference, scopes matching individual images are *in the fully expanded form*, either
using a tag or digest. For example, `docker.io/library/busybox:latest` (*not* `busybox:latest`).
More general named scopes are prefixes of individual-image scopes, and specify a repository (by omitting the tag or digest),
a repository namespace, or a registry host (by only specifying the host name and possibly a port number)
or a wildcarded expression starting with `*.`, for matching all subdomains (not including a port number). For wildcarded subdomain
matching, `*.example.com` is a valid case, but `example*.*.com` is not.
matching, `*.example.com` is a valid case, but `example*.*.com` is not.
### `oci:`
### `oci:`
The `oci:` transport refers to images in directories compliant with "Open Container Image Layout Specification".
The `oci:` transport refers to images in directories compliant with "Open Container Image Layout Specification".
Supported scopes use the form _directory_`:`_tag_, and _directory_ referring to
Supported scopes are paths to directories
a directory containing one or more tags, or any of the parent directories.
(either containing an OCI layout, or subdirectories possibly containing OCI layout directories).
The _reference_ annotation value, if any, is not used.
*Note:* See `dir:` above for semantics and restrictions on the directory paths, they apply to `oci:` equivalently.
*Note:*
- The paths must be absolute and contain no symlinks. Paths violating these requirements may be silently ignored.
- The top-level scope `"/"` is forbidden; use the transport default scope `""`,
for consistency with other transports.
### `tarball:`
### `oci-archive:`
Supported scopes are paths to OCI archives, and their parent directories
(either containing a single archive, or subdirectories possibly containing archives).
The _reference_ annotation value, if any, is not used.
*Note:*
- The paths must be absolute and contain no symlinks. Paths violating these requirements may be silently ignored.
- The top-level scope `"/"` is forbidden; use the transport default scope `""`,
for consistency with other transports.
### `ostree`:
The `tarball:` transport refers to tarred up container root filesystems.
Supported scopes have the form _repo-path_`:`_image-scope_; _repo_path_ is the path to the OSTree repository.
_image-scope_ is the _docker_reference_ part of the reference, with with a `:latest` tag implied if no tag is present,
and parent namespaces of the _docker_reference_ value (by omitting the tag, or a prefix specifying a higher-level namespace).
*Note:*
- The _repo_path_ must be absolute and contain no symlinks. Paths violating these requirements may be silently ignored.
### `sif:`
Supported scopes are paths to Singularity images, and their parent directories
(either containing images, or subdirectories possibly containing images).
*Note:*
- The paths must be absolute and contain no symlinks. Paths violating these requirements may be silently ignored.
- The top-level scope `"/"` is forbidden; use the transport default scope `""`,
for consistency with other transports.
### `tarball:`
Scopes are ignored.
The `tarball:` transport is an implementation detail of some import workflows. Only the default `""` scope is supported.
## Policy Requirements
## Policy Requirements
@ -149,20 +223,21 @@ This requirement rejects every image, and every signature.
### `signedBy`
### `signedBy`
This requirement requires an image to be signed with an expected identity, or accepts a signature if it is using an expected identity and key.
This requirement requires an image to be signed using “simple signing” with an expected identity, or accepts a signature if it is using an expected identity and key.
```js
```js
{
{
"type": "signedBy",
"type": "signedBy",
"keyType": "GPGKeys", /* The only currently supported value */
"keyType": "GPGKeys", /* The only currently supported value */
Exactly one of `keyPath` and `keyData` must be present, containing a GPG keyring of one or more public keys. Only signatures made by these keys are accepted.
Exactly one of `keyPath`, `keyPaths` and `keyData` must be present, containing a GPG keyring of one or more public keys. Only signatures made by these keys are accepted.
The `signedIdentity` field, a JSON object, specifies what image identity the signature claims about the image.
The `signedIdentity` field, a JSON object, specifies what image identity the signature claims about the image.
One of the following alternatives are supported:
One of the following alternatives are supported:
@ -236,6 +311,58 @@ used with `exactReference` or `exactRepository`.
<!-- ### `signedBaseLayer` -->
<!-- ### `signedBaseLayer` -->
### `sigstoreSigned`
This requirement requires an image to be signed using a sigstore signature with an expected identity and key.
Exactly one of `keyPath`, `keyPaths`, `keyData`, `keyDatas` and `fulcio` must be present.
If `keyPath` or `keyData` is present, it contains a sigstore public key.
Only signatures made by this key are accepted.
If `keyPaths` or `keyDatas` is present, it contains sigstore public keys.
Only signatures made by any key in the list are accepted.
If `fulcio` is present, the signature must be based on a Fulcio-issued certificate.
One of `caPath` and `caData` must be specified, containing the public key of the Fulcio instance.
Both `oidcIssuer` and `subjectEmail` are mandatory,
exactly specifying the expected identity provider,
and the identity of the user obtaining the Fulcio certificate.
At most one of `rekorPublicKeyPath`, `rekorPublicKeyPaths`, `rekorPublicKeyData` and `rekorPublicKeyDatas` can be present;
it is mandatory if `fulcio` is specified.
If a Rekor public key is specified,
the signature must have been uploaded to a Rekor server
and the signature must contain an (offline-verifiable) “signed entry timestamp”
proving the existence of the Rekor log record,
signed by one of the provided public keys.
The `signedIdentity` field has the same semantics as in the `signedBy` requirement described above.
Note that `cosign`-created signatures only contain a repository, so only `matchRepository` and `exactRepository` can be used to accept them (and that does not protect against substitution of a signed image with an unexpected tag).
To use this with images hosted on image registries, the `use-sigstore-attachments` option needs to be enabled for the relevant registry or repository in the client's containers-registries.d(5).
## Examples
## Examples
It is *strongly* recommended to set the `default` policy to `reject`, and then
It is *strongly* recommended to set the `default` policy to `reject`, and then
@ -255,9 +382,56 @@ selectively allow individual transports and scopes as desired.
@ -19,6 +19,12 @@ Container engines will use the `$HOME/.config/containers/registries.conf` if it
`credential-helpers`
`credential-helpers`
: An array of default credential helpers used as external credential stores. Note that "containers-auth.json" is a reserved value to use auth files as specified in containers-auth.json(5). The credential helpers are set to `["containers-auth.json"]` if none are specified.
: An array of default credential helpers used as external credential stores. Note that "containers-auth.json" is a reserved value to use auth files as specified in containers-auth.json(5). The credential helpers are set to `["containers-auth.json"]` if none are specified.
`additional-layer-store-auth-helper`
: A string containing the helper binary name. This enables passing registry credentials to an
Additional Layer Store every time an image is read using the `docker://`
transport so that it can access private registries. See the 'Enabling Additional Layer Store to access to private registries' section below for
more details.
### NAMESPACED `[[registry]]` SETTINGS
### NAMESPACED `[[registry]]` SETTINGS
The bulk of the configuration is represented as an array of `[[registry]]`
The bulk of the configuration is represented as an array of `[[registry]]`
@ -43,6 +49,8 @@ also include wildcarded subdomains in the format `*.example.com`.
The wildcard should only be present at the beginning as shown in the formats
The wildcard should only be present at the beginning as shown in the formats
above. Other cases will not work. For example, `*.example.com` is valid but
above. Other cases will not work. For example, `*.example.com` is valid but
`example.*.com`, `*.example.com/foo` and `*.example.com:5000/foo/bar:baz` are not.
`example.*.com`, `*.example.com/foo` and `*.example.com:5000/foo/bar:baz` are not.
Note that `*` matches an arbitrary number of subdomains. `*.example.com` will hence
match `bar.example.com`, `foo.bar.example.com` and so on.
As a special case, the `prefix` field can be missing; if so, it defaults to the value
As a special case, the `prefix` field can be missing; if so, it defaults to the value
of the `location` field (described below).
of the `location` field (described below).
@ -71,16 +79,16 @@ internet without having to change `Dockerfile`s, or to add redundancy).
: Accepts the same format as the `prefix` field, and specifies the physical location
: Accepts the same format as the `prefix` field, and specifies the physical location
of the `prefix`-rooted namespace.
of the `prefix`-rooted namespace.
By default, this equal to `prefix` (in which case `prefix` can be omitted and the
By default, this is equal to `prefix` (in which case `prefix` can be omitted and the
`[[registry]]` TOML table can only specify `location`).
`[[registry]]` TOML table can only specify `location`).
With a `prefix` containing a wildcard in the format: "*.example.com" for subdomain matching,
With a `prefix` containing a wildcard in the format: "*.example.com" for subdomain matching,
the location can be empty. In such a case,
the location can be empty. In such a case,
@ -97,30 +105,37 @@ as-is. But other settings like insecure/blocked/mirrors will be applied to match
`mirror`
`mirror`
: An array of TOML tables specifying (possibly-partial) mirrors for the
: An array of TOML tables specifying (possibly-partial) mirrors for the
`prefix`-rooted namespace.
`prefix`-rooted namespace (i.e., the current `[[registry]]` TOML table).
The mirrors are attempted in the specified order; the first one that can be
The mirrors are attempted in the specified order; the first one that can be
contacted and contains the image will be used (and if none of the mirrors contains the image,
contacted and contains the image will be used (and if none of the mirrors contains the image,
the primary location specified by the `registry.location` field, or using the unmodified
the primary location specified by the `registry.location` field, or using the unmodified
user-specified reference, is tried last).
user-specified reference, is tried last).
Each TOML table in the `mirror` array can contain the following fields, with the same semantics
Each TOML table in the `mirror` array can contain the following fields:
as if specified in the `[[registry]]` TOML table directly:
- `location`： same semantics
- `location`
as specified in the `[[registry]]` TOML table
- `insecure`
- `insecure`： same semantics
as specified in the `[[registry]]` TOML table
- `pull-from-mirror`: `all`, `digest-only` or `tag-only`. If "digest-only"， mirrors will only be used for digest pulls. Pulling images by tag can potentially yield different images, depending on which endpoint we pull from. Restricting mirrors to pulls by digest avoids that issue. If "tag-only", mirrors will only be used for tag pulls. For a more up-to-date and expensive mirror that it is less likely to be out of sync if tags move, it should not be unnecessarily used for digest references. Default is "all" (or left empty), mirrors will be used for both digest pulls and tag pulls unless the mirror-by-digest-only is set for the primary registry.
Note that this per-mirror setting is allowed only when `mirror-by-digest-only` is not configured for the primary registry.
`mirror-by-digest-only`
`mirror-by-digest-only`
: `true` or `false`.
: `true` or `false`.
If `true`, mirrors will only be used during pulling if the image reference includes a digest.
If `true`, mirrors will only be used during pulling if the image reference includes a digest.
Note that if all mirrors are configured to be digest-only, images referenced by a tag will only use the primary
registry.
If all mirrors are configured to be tag-only, images referenced by a digest will only use the primary
registry.
Referencing an image by digest ensures that the same is always used
Referencing an image by digest ensures that the same is always used
(whereas referencing an image by a tag may cause different registries to return
(whereas referencing an image by a tag may cause different registries to return
different images if the tag mapping is out of sync).
different images if the tag mapping is out of sync).
Note that if this is `true`, images referenced by a tag will only use the primary
registry, failing if that registry is not accessible.
*Note*: Redirection and mirrors are currently processed only when reading images, not when pushing
*Note*: Redirection and mirrors are currently processed only when reading a single image,
to a registry; that may change in the future.
not when pushing to a registry nor when doing any other kind of lookup/search on a on a registry.
This may change in the future.
#### Short-Name Aliasing
#### Short-Name Aliasing
The use of unqualified-search registries entails an ambiguity as it is
The use of unqualified-search registries entails an ambiguity as it is
Note that a mirror is associated only with the current `[[registry]]` TOML table. If using the example above, pulling the image `registry.com/image:latest` will hence only reach out to `mirror.registry.com`, and the mirrors associated with `example.com/foo` will not be considered.
### Enabling Additional Layer Store to access to private registries
The `additional-layer-store-auth-helper` option enables passing registry
credentials to an Additional Layer Store so that it can access private registries.
When accessing a private registry via an Additional Layer Store, a helper binary needs to be provided. This helper binary is
registered via the `additional-layer-store-auth-helper` option. Every time an image
is read using the `docker://` transport, the specified helper binary is executed
and receives registry credentials from stdin in the following format.
```json
{
"$image_reference": {
"username": "$username",
"password": "$password",
"identityToken": "$identityToken"
}
}
```
The format of `$image_reference` is `$repo{:$tag|@$digest}`.
Additional Layer Stores can use this helper binary to access the private registry.
## VERSION 1 FORMAT - DEPRECATED
## VERSION 1 FORMAT - DEPRECATED
VERSION 1 format is still supported but it does not support
VERSION 1 format is still supported but it does not support
using registry mirrors, longest-prefix matches, or location rewriting.
using registry mirrors, longest-prefix matches, or location rewriting.
@ -63,25 +63,31 @@ more general scopes is ignored. For example, if _any_ configuration exists for
### Built-in Defaults
### Built-in Defaults
If no `docker` section can be found for the container image, and no `default-docker` section is configured,
If no `docker` section can be found for the container image, and no `default-docker` section is configured:
the default directory, `/var/lib/containers/sigstore` for root and `$HOME/.local/share/containers/sigstore` for unprivileged user, will be used for reading and writing signatures.
- The default directory, `/var/lib/containers/sigstore` for root and `$HOME/.local/share/containers/sigstore` for unprivileged user, will be used for reading and writing signatures.
- Sigstore attachments will not be read/written.
## Individual Configuration Sections
## Individual Configuration Sections
A single configuration section is selected for a container image using the process
A single configuration section is selected for a container image using the process
described above. The configuration section is a YAML mapping, with the following keys:
described above. The configuration section is a YAML mapping, with the following keys:
- `sigstore-staging` defines an URL of of the signature storage, used for editing it (adding or deleting signatures).
<!-- `sigstore` and `sigstore-staging` are deprecated and intentionally not documented here. -->
- `lookaside-staging` defines an URL of of the signature storage, used for editing it (adding or deleting signatures).
This key is optional; if it is missing, `sigstore` below is used.
This key is optional; if it is missing, `lookaside` below is used.
- `sigstore` defines an URL of the signature storage.
- `lookaside` defines an URL of the signature storage.
This URL is used for reading existing signatures,
This URL is used for reading existing signatures,
and if `sigstore-staging` does not exist, also for adding or removing them.
and if `lookaside-staging` does not exist, also for adding or removing them.
This key is optional; if it is missing, no signature storage is defined (no signatures
This key is optional; if it is missing, no signature storage is defined (no signatures
are download along with images, adding new signatures is possible only if `sigstore-staging` is defined).
are download along with images, adding new signatures is possible only if `lookaside-staging` is defined).
- `use-sigstore-attachments` specifies whether sigstore image attachments (signatures, attestations and the like) are going to be read/written along with the image.
If disabled, the images are treated as if no attachments exist; attempts to write attachments fail.
## Examples
## Examples
@ -92,11 +98,11 @@ The following demonstrates how to to consume and run images from various registr
@ -27,8 +27,7 @@ No bare options are used. The format of TOML can be simplified to:
The `storage` table supports the following options:
The `storage` table supports the following options:
**driver**=""
**driver**=""
container storage driver
Copy On Write (COW) container storage driver. Valid drivers are "overlay", "vfs", "aufs", "btrfs", and "zfs". Some drivers (for example, "zfs", "btrfs", and "aufs") may not work if your kernel lacks support for the filesystem.
Default Copy On Write (COW) container storage driver. Valid drivers are "overlay", "vfs", "devmapper", "aufs", "btrfs", and "zfs". Some drivers (for example, "zfs", "btrfs", and "aufs") may not work if your kernel lacks support for the filesystem.
This field is required to guarantee proper operation.
This field is required to guarantee proper operation.
Valid rootless drivers are "btrfs", "overlay", and "vfs".
Valid rootless drivers are "btrfs", "overlay", and "vfs".
Rootless users default to the driver defined in the system configuration when possible.
Rootless users default to the driver defined in the system configuration when possible.
@ -37,35 +36,46 @@ The `storage` table supports the following options:
**graphroot**=""
**graphroot**=""
container storage graph dir (default: "/var/lib/containers/storage")
container storage graph dir (default: "/var/lib/containers/storage")
Default directory to store all writable content created by container storage programs.
Default directory to store all writable content created by container storage programs.
The rootless graphroot path supports environment variable substitutions (ie. `$HOME/containers/storage`)
The rootless graphroot path supports environment variable substitutions (ie. `$HOME/containers/storage`).
When changing the graphroot location on an SELINUX system, ensure
When changing the graphroot location on an SELINUX system, ensure the labeling matches the default locations labels with the following commands:
the labeling matches the default locations labels with the
following commands:
```
```
# semanage fcontext -a -e /var/lib/containers/storage /NEWSTORAGEPATH
# semanage fcontext -a -e /var/lib/containers/storage /NEWSTORAGEPATH
# restorecon -R -v /NEWSTORAGEPATH
# restorecon -R -v /NEWSTORAGEPATH
```
```
In Rootless Mode you would set
In rootless mode you would set
```
```
# semanage fcontext -a -e $HOME/.local/share/containers NEWSTORAGEPATH
# semanage fcontext -a -e $HOME/.local/share/containers NEWSTORAGEPATH
Storage path for rootless users. By default the graphroot for rootless users
Storage path for rootless users. By default the graphroot for rootless users is set to `$XDG_DATA_HOME/containers/storage`, if XDG_DATA_HOME is set. Otherwise `$HOME/.local/share/containers/storage` is used. This field can be used if administrators need to change the storage location for all users. The rootless storage path supports environment variable substitutions (ie. `$HOME/containers/storage`)
is set to `$XDG_DATA_HOME/containers/storage`, if XDG_DATA_HOME is set.
Otherwise `$HOME/.local/share/containers/storage` is used. This field can
be used if administrators need to change the storage location for all users.
The rootless storage path supports environment variable substitutions (ie. `$HOME/containers/storage`)
A common use case for this field is to provide a local storage directory when user home directories are NFS-mounted (podman does not support container storage over NFS).
A common use case for this field is to provide a local storage directory when user home directories are NFS-mounted (podman does not support container storage over NFS).
**imagestore**=""
The image storage path (the default is assumed to be the same as `graphroot`). Path of the imagestore, which is different from `graphroot`. By default, images in the storage library are stored in the `graphroot`. If `imagestore` is provided, newly pulled images will be stored in the `imagestore` location. All other storage continues to be stored in the `graphroot`. When using the `overlay` driver, images previously stored in the `graphroot` remain accessible. Internally, the storage library mounts `graphroot` as an `additionalImageStore` to allow this behavior.
A common use case for the `imagestore` field is users who need to split filesystems in different partitions. The `imagestore` partition stores images and the `graphroot` partition stores container content created from the images.
Imagestore, if set, must be different from `graphroot`.
**runroot**=""
**runroot**=""
container storage run dir (default: "/run/containers/storage")
container storage run dir (default: "/run/containers/storage")
Default directory to store all temporary writable content created by container storage programs.
Default directory to store all temporary writable content created by container storage programs. The rootless runroot path supports environment variable substitutions (ie. `$HOME/containers/storage`)
The rootless runroot path supports environment variable substitutions (ie. `$HOME/containers/storage`)
**driver_priority**=[]
Priority list for the storage drivers that will be tested one after the other to pick the storage driver if it is not defined. The first storage driver in this list that can be used, will be picked as the new one and all subsequent ones will not be tried. If all drivers in this list are not viable, then **all** known drivers will be tried and the first working one will be picked.
By default, the storage driver is set via the `driver` option. If it is not defined, then the best driver will be picked according to the current platform. This option allows you to override this internal priority list with a custom one to prefer certain drivers.
Setting this option only has an effect if the local storage has not been initialized yet and the driver name is not set.
**transient_store** = "false" | "true"
Transient store mode makes all container metadata be saved in temporary storage
(i.e. runroot above). This is faster, but doesn't persist across reboots.
Additional garbage collection must also be performed at boot-time, so this option should remain disabled in most configurations. (default: false)
### STORAGE OPTIONS TABLE
### STORAGE OPTIONS TABLE
@ -74,23 +84,32 @@ The `storage.options` table supports the following options:
**additionalimagestores**=[]
**additionalimagestores**=[]
Paths to additional container image stores. Usually these are read/only and stored on remote network shares.
Paths to additional container image stores. Usually these are read/only and stored on remote network shares.
Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of a container, to the UIDs/GIDs outside of the container, and the length of the range of UIDs/GIDs. Additional mapped sets can be listed and will be heeded by libraries, but there are limits to the number of mappings which the kernel will allow when you later attempt to run a container.
Allows specification of how storage is populated when pulling images. This
option can speed the pulling process of images compressed with format zstd:chunked. Containers/storage looks
Example
for files within images that are being pulled from a container registry that
remap-uids = 0:1668442479:65536
were previously pulled to the host. It can copy or create
remap-gids = 0:1668442479:65536
a hard link to the existing file when it finds them, eliminating the need to pull them from the
container registry. These options can deduplicate pulling of content, disk
These mappings tell the container engines to map UID 0 inside of the container to UID 1668442479 outside. UID 1 will be mapped to 1668442480. UID 2 will be mapped to 1668442481, etc, for the next 65533 UIDs in succession.
storage of content and can allow the kernel to use less memory when running
containers.
**remap-user**=""
**remap-group**=""
containers/storage supports four keys
Remap-User/Group is a user name which can be used to look up one or more UID/GID ranges in the /etc/subuid or /etc/subgid file. Mappings are set up starting with an in-container ID of 0 and then a host-level ID taken from the lowest range that matches the specified name, and using the length of that range. Additional ranges are then assigned, using the ranges which specify the lowest host-level IDs first, to the lowest not-yet-mapped in-container ID, until all of the entries have been used for maps.
* enable_partial_images="true" | "false"
Tells containers/storage to look for files previously pulled in storage
Example
rather then always pulling them from the container registry.
remap-user = "containers"
* use_hard_links = "false" | "true"
remap-group = "containers"
Tells containers/storage to use hard links rather then create new files in
the image, if an identical file already existed in storage.
* ostree_repos = ""
Tells containers/storage where an ostree repository exists that might have
previously pulled content which can be used when attempting to avoid
pulling content from the container registry
* convert_images = "false" | "true"
If set to true, containers/storage will convert images to a format compatible with
partial pulls in order to take advantage of local deduplication and hardlinking. It is an
expensive operation so it is not enabled by default.
**root-auto-userns-user**=""
**root-auto-userns-user**=""
Root-auto-userns-user is a user name which can be used to look up one or more UID/GID ranges in the /etc/subuid and /etc/subgid file. These ranges will be partitioned to containers configured to create automatically a user namespace. Containers configured to automatically create a user namespace can still overlap with containers having an explicit mapping set. This setting is ignored when running as rootless.
Root-auto-userns-user is a user name which can be used to look up one or more UID/GID ranges in the /etc/subuid and /etc/subgid file. These ranges will be partitioned to containers configured to create automatically a user namespace. Containers configured to automatically create a user namespace can still overlap with containers having an explicit mapping set. This setting is ignored when running as rootless.
@ -121,66 +140,6 @@ The `storage.options.btrfs` table supports the following options:
**size**=""
**size**=""
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
### STORAGE OPTIONS FOR THINPOOL (devicemapper) TABLE
The `storage.options.thinpool` table supports the following options for the `devicemapper` driver:
**autoextend_percent**=""
Tells the thinpool driver the amount by which the thinpool needs to be grown. This is specified in terms of % of pool size. So a value of 20 means that when threshold is hit, pool will be grown by 20% of existing pool size. (default: 20%)
**autoextend_threshold**=""
Tells the driver the thinpool extension threshold in terms of percentage of pool size. For example, if threshold is 60, that means when pool is 60% full, threshold has been hit. (default: 80%)
**basesize**=""
Specifies the size to use when creating the base device, which limits the size of images and containers. (default: 10g)
**blocksize**=""
Specifies a custom blocksize to use for the thin pool. (default: 64k)
**directlvm_device**=""
Specifies a custom block storage device to use for the thin pool. Required for using graphdriver `devicemapper`.
**directlvm_device_force**=""
Tells driver to wipe device (directlvm_device) even if device already has a filesystem. (default: false)
**fs**="xfs"
Specifies the filesystem type to use for the base device. (default: xfs)
**log_level**=""
Sets the log level of devicemapper.
0: LogLevelSuppress 0 (default)
2: LogLevelFatal
3: LogLevelErr
4: LogLevelWarn
5: LogLevelNotice
6: LogLevelInfo
7: LogLevelDebug
**metadata_size**=""
metadata_size is used to set the `pvcreate --metadatasize` options when creating thin devices. (Default 128k)
**min_free_space**=""
Specifies the min free space percent in a thin pool required for new device creation to succeed. Valid values are from 0% - 99%. Value 0% disables. (default: 10%)
**mkfsarg**=""
Specifies extra mkfs arguments to be used when creating the base device.
**mountopt**=""
Comma separated list of default options to be used to mount container images. Suggested value "nodev". Mount options are documented in the mount(8) man page.
**size**=""
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
**use_deferred_deletion**=""
Marks thinpool device for deferred deletion. If the thinpool is in use when the driver attempts to delete it, the driver will attempt to delete device every 30 seconds until successful, or when it restarts. Deferred deletion permanently deletes the device and all data stored in the device will be lost. (default: true).
**use_deferred_removal**=""
Marks devicemapper block device for deferred removal. If the device is in use when its driver attempts to remove it, the driver tells the kernel to remove the device as soon as possible. Note this does not free up the disk space, use deferred deletion to fully remove the thinpool. (default: true).
**xfs_nospace_max_retries**=""
Specifies the maximum number of retries XFS should attempt to complete IO when ENOSPC (no space) error is returned by underlying storage device. (default: 0, which means to try continuously.)
### STORAGE OPTIONS FOR OVERLAY TABLE
### STORAGE OPTIONS FOR OVERLAY TABLE
The `storage.options.overlay` table supports the following options:
The `storage.options.overlay` table supports the following options:
@ -193,20 +152,19 @@ The `storage.options.overlay` table supports the following options:
**force_mask** = "0000|shared|private"
**force_mask** = "0000|shared|private"
ForceMask specifies the permissions mask that is used for new files and
ForceMask specifies the permissions mask that is used for new files and
directories.
directories. The values "shared" and "private" are accepted. (default: ""). Octal permission
The values "shared" and "private" are accepted. (default: ""). Octal permission
masks are also accepted.
masks are also accepted.
``: Not set
- ``: Not set
All files/directories, get set with the permissions identified within the
All files/directories, get set with the permissions identified within the
image.
image.
`private`: it is equivalent to 0700.
-`private`: it is equivalent to 0700.
All files/directories get set with 0700 permissions. The owner has rwx
All files/directories get set with 0700 permissions. The owner has rwx
access to the files. No other users on the system can access the files.
access to the files. No other users on the system can access the files.
This setting could be used with networked based home directories.
This setting could be used with networked based home directories.
`shared`: it is equivalent to 0755.
-`shared`: it is equivalent to 0755.
The owner has rwx access to the files and everyone else can read, access
The owner has rwx access to the files and everyone else can read, access
and execute them. This setting is useful for sharing containers storage
and execute them. This setting is useful for sharing containers storage
with other users. For instance, a storage owned by root could be shared
with other users. For instance, a storage owned by root could be shared
@ -221,7 +179,7 @@ Note: The force_mask Flag is an experimental feature, it could change in the
future. When "force_mask" is set the original permission mask is stored in the
future. When "force_mask" is set the original permission mask is stored in the
"user.containers.override_stat" xattr and the "mount_program" option must be
"user.containers.override_stat" xattr and the "mount_program" option must be
specified. Mount programs like "/usr/bin/fuse-overlayfs" present the extended
specified. Mount programs like "/usr/bin/fuse-overlayfs" present the extended
attribute permissions to processes within containers rather then the
attribute permissions to processes within containers rather than the
"force_mask" permissions.
"force_mask" permissions.
**mount_program**=""
**mount_program**=""
@ -236,9 +194,15 @@ based file systems.
**mountopt**=""
**mountopt**=""
Comma separated list of default options to be used to mount container images. Suggested value "nodev". Mount options are documented in the mount(8) man page.
Comma separated list of default options to be used to mount container images. Suggested value "nodev". Mount options are documented in the mount(8) man page.
**skip_mount_home=""**
Tell storage drivers to not create a PRIVATE bind mount on their home directory.
**size**=""
**size**=""
Maximum size of a read/write layer. This flag can be used to set quota on the size of a read/write layer of a container. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
Maximum size of a read/write layer. This flag can be used to set quota on the size of a read/write layer of a container. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
**use_composefs** = "false"
Use ComposeFS to mount the data layers image. ComposeFS support is experimental and not recommended for production use. (default: false)
### STORAGE OPTIONS FOR VFS TABLE
### STORAGE OPTIONS FOR VFS TABLE
The `storage.options.vfs` table supports the following options:
The `storage.options.vfs` table supports the following options:
@ -256,9 +220,6 @@ The `storage.options.zfs` table supports the following options:
**mountopt**=""
**mountopt**=""
Comma separated list of default options to be used to mount container images. Suggested value "nodev". Mount options are documented in the mount(8) man page.
Comma separated list of default options to be used to mount container images. Suggested value "nodev". Mount options are documented in the mount(8) man page.
**skip_mount_home=""**
Tell storage drivers to not create a PRIVATE bind mount on their home directory.
**size**=""
**size**=""
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
@ -317,7 +278,7 @@ This is a way to prevent xfs_quota management from conflicting with containers/s
Distributions often provide a `/usr/share/containers/storage.conf` file to define default storage configuration. Administrators can override this file by creating `/etc/containers/storage.conf` to specify their own configuration. Likewise rootless users can create a storage.conf file to override the system storage.conf files. Files should be stored in the `$XDG_CONFIG_HOME/containers/storage.conf` file. If `$XDG_CONFIG_HOME` is not set then the file `$HOME/.config/containers/storage.conf` is used.
Distributions often provide a `/usr/share/containers/storage.conf` file to define default storage configuration. Administrators can override this file by creating `/etc/containers/storage.conf` to specify their own configuration. Likewise rootless users can create a storage.conf file to override the system storage.conf files. Files should be stored in the `$XDG_CONFIG_HOME/containers/storage.conf` file. If `$XDG_CONFIG_HOME` is not set then the file `$HOME/.config/containers/storage.conf` is used.
Note: The storage.conf file overrides all other strorage.conf files. Container
Note: The storage.conf file overrides all other storage.conf files. Container
engines run by users with a storage.conf file in their home directory do not
engines run by users with a storage.conf file in their home directory do not
@ -9,16 +9,23 @@ containers-transports - description of supported transports for copying and stor
## DESCRIPTION
## DESCRIPTION
Tools which use the containers/image library, including skopeo(1), buildah(1), podman(1), all share a common syntax for referring to container images in various locations.
Tools which use the containers/image library, including skopeo(1), buildah(1), podman(1), all share a common syntax for referring to container images in various locations.
The general form of the syntax is _transport:details_, where details are dependent on the specified transport, which are documented below.
The general form of the syntax is _transport_`:`_details_, where details are dependent on the specified transport, which are documented below.
The format of _docker-reference_ is described in detail in the **docker** transport.
The format of _docker-reference_ is described in detail in the **docker** transport.
The _storage-specifier_ allows for referencing storage locations on the file system and has the format `[[driver@]root[+run-root][:options]]` where the optional `driver` refers to the storage driver (e.g., overlay or btrfs) and where `root` is an absolute path to the storage's root directory.
The _storage-specifier_ allows for referencing storage locations on the file system and has the format `[`[_driver_`@`]_root_[`+`_run-root_][`:`_options_]`]` where the optional _driver_ refers to the storage driver (e.g., `overlay` or `btrfs`) and where _root_ is an absolute path to the storage's root directory.
The optional `run-root` can be used to specify the run directory of the storage where all temporary writable content is stored.
The optional _run-root_ can be used to specify the run directory of the storage where all temporary writable content is stored.
The optional `options` are a comma-separated list of driver-specific options.
The optional _options_ are a comma-separated list of driver-specific options.
Please refer to containers-storage.conf(5) for further information on the drivers and supported options.
Please refer to containers-storage.conf(5) for further information on the drivers and supported options.
### **dir:**_path_
### **dir:**_path_
@ -33,43 +40,68 @@ By default, uses the authorization state in `$XDG_RUNTIME_DIR/containers/auth.js
If the authorization state is not found there, `$HOME/.docker/config.json` is checked, which is set using docker-login(1).
If the authorization state is not found there, `$HOME/.docker/config.json` is checked, which is set using docker-login(1).
The containers-registries.conf(5) further allows for configuring various settings of a registry.
The containers-registries.conf(5) further allows for configuring various settings of a registry.
Note that a _docker-reference_ has the following format: `name[:tag|@digest]`.
Note that a _docker-reference_ has the following format: _name_[`:`_tag_ | `@`_digest_].
While the docker transport does not support both a tag and a digest at the same time some formats like containers-storage do.
While the docker transport does not support both a tag and a digest at the same time some formats like containers-storage do.
Digests can also be used in an image destination as long as the manifest matches the provided digest.
Digests can also be used in an image destination as long as the manifest matches the provided digest.
The docker transport supports pushing images without a tag or digest to a registry when the image name is suffixed with `@@unknown-digest@@`. The _name_`@@unknown-digest@@` reference format cannot be used with a reference that has a tag or digest.
The digest of images can be explored with skopeo-inspect(1).
The digest of images can be explored with skopeo-inspect(1).
If `name` does not contain a slash, it is treated as `docker.io/library/name`.
Otherwise, the component before the first slash is checked if it is recognized as a `hostname[:port]` (i.e., it contains either a . or a :, or the component is exactly localhost).
If the first component of name is not recognized as a `hostname[:port]`, `name` is treated as `docker.io/name`.
If _name_ does not contain a slash, it is treated as `docker.io/library/`_name_.
Otherwise, the component before the first slash is checked if it is recognized as a _hostname_[`:`_port_] (i.e., it contains either a `.` or a `:`, or the component is exactly `localhost`).
If the first component of name is not recognized as a _hostname_[`:`_port_], _name_ is treated as `docker.io/`_name_.
Files in those locations are not loaded by default but only on-demand. They are loaded after all system and user configuration files but before `CONTAINERS_CONF_OVERRIDE` hence allowing for overriding system and user configs.
Modules are currently supported by podman(1). The `podman --module` flag allows for loading a module and can be specified multiple times. If the specified value is an absolute path, the config file will be loaded directly. Relative paths are resolved relative to the three module directories mentioned above and in the specified order such that modules in `$XDG_CONFIG_HOME/$HOME` allow for overriding those in `/etc` and `/usr/share`.
## APPENDING TO STRING ARRAYS
The default behavior during the loading sequence of multiple containers.conf files is to override previous data. To change the behavior from overriding to appending, you can set the `append` attribute as follows: `array=["item-1", "item=2", ..., {append=true}]`. Setting the append attribute instructs to append to this specific string array for the current and also subsequent loading steps. To change back to overriding, set `{append=false}`.
Consider the following example:
```
modules1.conf: env=["1=true"]
modules2.conf: env=["2=true"]
modules3.conf: env=["3=true", {append=true}]
modules4.conf: env=["4=true"]
```
After loading the files in the given order, the final contents are `env=["2=true", "3=true", "4=true"]`. If modules4.conf would set `{append=false}`, the final contents would be `env=["4=true"]`.
# FORMAT
# FORMAT
The [TOML format][toml] is used as the encoding of the configuration file.
The [TOML format][toml] is used as the encoding of the configuration file.
Every option is nested under its table. No bare options are used. The format of
Every option is nested under its table. No bare options are used. The format of
@ -50,6 +84,7 @@ TOML can be simplified to:
The containers table contains settings to configure and manage the OCI runtime.
The containers table contains settings to configure and manage the OCI runtime.
**annotations** = []
**annotations** = []
List of annotations. Specified as "key=value" pairs to be added to all containers.
List of annotations. Specified as "key=value" pairs to be added to all containers.
Environment variable list for the container process, used for passing
Environment variable list for the container process, used for passing
environment variables to the container.
environment variables to the container.
@ -143,6 +193,16 @@ environment variables to the container.
Pass all host environment variables into the container.
Pass all host environment variables into the container.
**host_containers_internal_ip**=""
Set the ip for the host.containers.internal entry in the containers /etc/hosts
file. This can be set to "none" to disable adding this entry. By default it
will automatically choose the host ip.
NOTE: When using podman machine this entry will never be added to the containers
hosts file instead the gvproxy dns resolver will resolve this hostname. Therefore
it is not possible to disable the entry in this case.
**http_proxy**=true
**http_proxy**=true
Default proxy environment variables will be passed into the container.
Default proxy environment variables will be passed into the container.
@ -158,16 +218,29 @@ Run an init inside the container that forwards signals and reaps processes.
**init_path**="/usr/libexec/podman/catatonit"
**init_path**="/usr/libexec/podman/catatonit"
If this option is not set catatonit is searched in the directories listed under
the **helper_binaries_dir** option. It is recommended to just install catatonit
there instead of configuring this option here.
Path to the container-init binary, which forwards signals and reaps processes
Path to the container-init binary, which forwards signals and reaps processes
within containers. Note that the container-init binary will only be used when
within containers. Note that the container-init binary will only be used when
the `--init` for podman-create and podman-run is set.
the `--init` for podman-create and podman-run is set.
**ipcns**="private"
**interface_name**=""
Default way to to create a IPC namespace for the container.
Default way to set interface names inside containers. Defaults to legacy pattern
of ethX, where X is an integer, when left undefined.
Options are:
`device` Uses the network_interface name from the network config as interface name. Falls back to the ethX pattern if the network_interface is not set.
**ipcns**="shareable"
Default way to create a IPC namespace for the container.
Options are:
Options are:
`private` Create private IPC Namespace for the container.
`host` Share host IPC Namespace with the container.
`host` Share host IPC Namespace with the container.
`none` Create shareable IPC Namespace for the container without a private /dev/shm.
`private` Create private IPC Namespace for the container, other containers are not allowed to share it.
`shareable` Create shareable IPC Namespace for the container.
**keyring**=true
**keyring**=true
@ -178,9 +251,16 @@ the container.
Indicates whether the container engine uses MAC(SELinux) container separation via labeling. This option is ignored on disabled systems.
Indicates whether the container engine uses MAC(SELinux) container separation via labeling. This option is ignored on disabled systems.
**log_driver**="k8s-file"
**label_users**=false
label_users indicates whether to enforce confined users in containers on
SELinux systems. This option causes containers to maintain the current user
and role field of the calling process. By default SELinux containers run with
the user system_u, and the role system_r.
Logging driver for the container. Available options: `k8s-file` and `journald`.
**log_driver**=""
Logging driver for the container. Currently available options are k8s-file, journald, none and passthrough, with json-file aliased to k8s-file for scripting compatibility. The journald driver is used by default if the systemd journal is readable and writable. Otherwise, the k8s-file driver is used.
**log_size_max**=-1
**log_size_max**=-1
@ -193,9 +273,16 @@ limit is never exceeded.
Default format tag for container log messages. This is useful for creating a specific tag for container log messages. Container log messages default to using the truncated container ID as a tag.
Default format tag for container log messages. This is useful for creating a specific tag for container log messages. Container log messages default to using the truncated container ID as a tag.
**mounts**=[]
List of mounts.
Specified as "type=TYPE,source=<directory-on-host>,destination=<directory-in-container>,<options>"
Default way to to create a NET namespace for the container.
Default way to create a NET namespace for the container.
Options are:
Options are:
`private` Create private NET Namespace for the container.
`private` Create private NET Namespace for the container.
`host` Share host NET Namespace with the container.
`host` Share host NET Namespace with the container.
@ -206,9 +293,13 @@ Options are:
Create /etc/hosts for the container. By default, container engines manage
Create /etc/hosts for the container. By default, container engines manage
/etc/hosts, automatically adding the container's own IP address.
/etc/hosts, automatically adding the container's own IP address.
**oom_score_adj**=0
Tune the host's OOM preferences for containers (accepts values from -1000 to 1000).
**pidns**="private"
**pidns**="private"
Default way to to create a PID namespace for the container.
Default way to create a PID namespace for the container.
Options are:
Options are:
`private` Create private PID Namespace for the container.
`private` Create private PID Namespace for the container.
`host` Share host PID Namespace with the container.
`host` Share host PID Namespace with the container.
@ -222,6 +313,16 @@ is imposed.
Copy the content from the underlying image into the newly created volume when the container is created instead of when it is started. If `false`, the container engine will not copy the content until the container is started. Setting it to `true` may have negative performance implications.
Copy the content from the underlying image into the newly created volume when the container is created instead of when it is started. If `false`, the container engine will not copy the content until the container is started. Setting it to `true` may have negative performance implications.
**privileged**=false
Give extended privileges to all containers. A privileged container turns off the security features that isolate the container from the host. Dropped Capabilities, limited devices, read-only mount points, Apparmor/SELinux separation, and Seccomp filters are all disabled. Due to the disabled security features, the privileged field should almost never be set as containers can easily break out of confinment.
Containers running in a user namespace (e.g., rootless containers) cannot have more privileges than the user that launched them.
**read_only**=true|false
Run all containers with root file system mounted read-only. Set to false by default.
Path to the OCI hooks directories for automatically executed hooks.
Path to the OCI hooks directories for automatically executed hooks.
**cdi_spec_dirs**=["/etc/cdi", ...]
Directories to scan for CDI Spec files.
**image_default_format**="oci"|"v2s2"|"v2s1"
**image_default_format**="oci"|"v2s2"|"v2s1"
Manifest Type (oci, v2s2, or v2s1) to use when pulling, pushing, building
Manifest Type (oci, v2s2, or v2s1) to use when pulling, pushing, building
@ -433,22 +674,34 @@ Default transport method for pulling and pushing images.
Maximum number of image layers to be copied (pulled/pushed) simultaneously.
Maximum number of image layers to be copied (pulled/pushed) simultaneously.
Not setting this field will fall back to containers/image defaults. (6)
Not setting this field will fall back to containers/image defaults. (6)
**image_volume_mode**="bind"
Tells container engines how to handle the built-in image volumes.
* bind: An anonymous named volume will be created and mounted into the container.
* tmpfs: The volume is mounted onto the container as a tmpfs, which allows the users to create content that disappears when the container is stopped.
* ignore: All volumes are just ignored and no action is taken.
**infra_command**="/pause"
**infra_command**="/pause"
Infra (pause) container image command for pod infra containers. When running a
Infra (pause) container image command for pod infra containers. When running a
pod, we start a `/pause` process in a container to hold open the namespaces
pod, we start a `/pause` process in a container to hold open the namespaces
associated with the pod. This container does nothing other then sleep,
associated with the pod. This container does nothing other than sleep,
reserving the pods resources for the lifetime of the pod.
reserving the pod's resources for the lifetime of the pod.
**infra_image**=""
**infra_image**=""
Infra (pause) container image for pod infra containers. When running a
Infra (pause) container image for pod infra containers. When running a
pod, we start a `pause` process in a container to hold open the namespaces
pod, we start a `pause` process in a container to hold open the namespaces
associated with the pod. This container does nothing other then sleep,
associated with the pod. This container does nothing other than sleep,
reserving the pods resources for the lifetime of the pod. By default container
reserving the pod's resources for the lifetime of the pod. By default container
engines run a builtin container using the pause executable. If you want override
engines run a built-in container using the pause executable. If you want override
specify an image to pull.
specify an image to pull.
**kube_generate_type**="pod"
Default Kubernetes kind/specification of the kubernetes yaml generated with the `podman kube generate` command. The possible options are `pod` and `deployment`.
**lock_type**="shm"
**lock_type**="shm"
Specify the locking mechanism to use; valid values are "shm" and "file".
Specify the locking mechanism to use; valid values are "shm" and "file".
@ -457,12 +710,6 @@ Change the default only if you are sure of what you are doing, in general
faster "shm" lock type. You may need to run "podman system renumber" after you
faster "shm" lock type. You may need to run "podman system renumber" after you
change the lock type.
change the lock type.
**machine_enabled**=false
Indicates if Podman is running inside a VM via Podman Machine.
Podman uses this value to do extra setup around networking from the
container inside the VM to to host.
**multi_image_archive**=false
**multi_image_archive**=false
Allows for creating archives (e.g., tarballs) with more than one image. Some container engines, such as Podman, interpret additional arguments as tags for one image and hence do not store more than one image. The default behavior can be altered with this option.
Allows for creating archives (e.g., tarballs) with more than one image. Some container engines, such as Podman, interpret additional arguments as tags for one image and hence do not store more than one image. The default behavior can be altered with this option.
@ -479,16 +726,16 @@ and pods are visible.
Path to the slirp4netns binary.
Path to the slirp4netns binary.
**network_cmd_options**=["enable_ipv6=true",]
**network_cmd_options**=[]
Default options to pass to the slirp4netns binary.
Default options to pass to the slirp4netns binary.
Valid options values are:
Valid options values are:
- **allow_host_loopback=true|false**: Allow the slirp4netns to reach the host loopback IP (`10.0.2.2`, which is added to `/etc/hosts` as `host.containers.internal` for your convenience). Default is false.
- **allow_host_loopback=true|false**: Allow the slirp4netns to reach the host loopback IP (`10.0.2.2`). Default is false.
- **mtu=MTU**: Specify the MTU to use for this network. (Default is `65520`).
- **mtu=MTU**: Specify the MTU to use for this network. (Default is `65520`).
- **cidr=CIDR**: Specify ip range to use for this network. (Default is `10.0.2.0/24`).
- **cidr=CIDR**: Specify ip range to use for this network. (Default is `10.0.2.0/24`).
- **enable_ipv6=true|false**: Enable IPv6. Default is false. (Required for `outbound_addr6`).
- **enable_ipv6=true|false**: Enable IPv6. Default is true. (Required for `outbound_addr6`).
- **outbound_addr=INTERFACE**: Specify the outbound interface slirp should bind to (ipv4 traffic only).
- **outbound_addr=INTERFACE**: Specify the outbound interface slirp should bind to (ipv4 traffic only).
- **outbound_addr=IPv4**: Specify the outbound ipv4 address slirp should bind to.
- **outbound_addr=IPv4**: Specify the outbound ipv4 address slirp should bind to.
- **outbound_addr6=INTERFACE**: Specify the outbound interface slirp should bind to (ipv6 traffic only).
- **outbound_addr6=INTERFACE**: Specify the outbound interface slirp should bind to (ipv6 traffic only).
@ -503,10 +750,20 @@ Whether to use chroot instead of pivot_root in the runtime.
**num_locks**=2048
**num_locks**=2048
Number of locks available for containers and pods. Each created container or
Number of locks available for containers, pods, and volumes.
pod consumes one lock. The default number available is 2048. If this is
Each created container, pod, or volume consumes one lock.
changed, a lock renumbering must be performed, using the
Locks are recycled and can be reused after the associated container, pod, or volume is removed.
`podman system renumber` command.
The default number available is 2048.
If this is changed, a lock renumbering must be performed, using the `podman system renumber` command.
**pod_exit_policy**="continue"
Set the exit policy of the pod when the last container exits. Supported policies are:
| *continue* | The pod continues running when the last container exits. Used by default. |
| *stop* | The pod is stopped when the last container exits. Used in `play kube`. |
**pull_policy**="always"|"missing"|"never"
**pull_policy**="always"|"missing"|"never"
@ -517,16 +774,25 @@ Pull image before running or creating a container. The default is **missing**.
- **never**: do not pull the image from the registry, use only the local version. Raise an error if the image is not present locally.
- **never**: do not pull the image from the registry, use only the local version. Raise an error if the image is not present locally.
**remote** = false
**remote** = false
Indicates whether the application should be running in remote mode. This flag modifies the
Indicates whether the application should be running in remote mode. This flag modifies the
--remote option on container engines. Setting the flag to true will default `podman --remote=true` for access to the remote Podman service.
--remote option on container engines. Setting the flag to true will default `podman --remote=true` for access to the remote Podman service.
**retry** = 3
Number of times to retry pulling/pushing images in case of failure.
**retry_delay** = ""
Delay between retries in case pulling/pushing image fails. If set, container engines will retry at the set interval, otherwise they delay 2 seconds and then exponentially back off.
**runtime**=""
**runtime**=""
Default OCI specific runtime in runtimes that will be used by default. Must
Default OCI specific runtime in runtimes that will be used by default. Must
refer to a member of the runtimes table. Default runtime will be searched for
refer to a member of the runtimes table. Default runtime will be searched for
on the system using the priority: "crun", "runc", "kata".
on the system using the priority: "crun", "runc", "runj", "kata", "runsc", "ocijail"
Virtualization provider to be used for running a podman-machine VM. Empty value
is interpreted as the default provider for the current host OS. On Linux/Mac
default is `QEMU` and on Windows it is `WSL`.
**rosetta**="true"
Rosetta supports running x86_64 Linux binaries on a Podman machine on Apple silicon.
The default value is `true`. Supported on AppleHV(arm64) machines only.
## FARMS TABLE
The `farms` table contains configuration options used to group up remote connections into farms that will be used when sending out builds to different machines in a farm via `podman buildfarm`.
**default**=""
The default farm to use when farming out builds.
**[farms.list]**
Map of farms created where the key is the farm name and the value is the list of system connections.
## PODMANSH TABLE
The `podmansh` table contains configuration options used by podmansh.
**shell**="/bin/sh"
The shell to spawn in the container.
The default value is `/bin/sh`.
**container**="podmansh"
Name of the container that podmansh joins.
The default value is `podmansh`.
**timeout**=0
Number of seconds to wait for podmansh logins. This value if favoured over the deprecated field `engine.podmansh_timeout` if set.
The default value is 30.
# FILES
# FILES
**containers.conf**
**containers.conf**
Distributions often provide a `/usr/share/containers/containers.conf` file to
Distributions often provide a __/usr/share/containers/containers.conf__ file to
define default container configuration. Administrators can override fields in
provide a default configuration. Administrators can override fields in this
this file by creating `/etc/containers/containers.conf` to specify their own
file by creating __/etc/containers/containers.conf__ to specify their own
configuration. Rootless users can further override fields in the config by
configuration. They may also drop `.conf` files in
creating a config file stored in the `$HOME/.config/containers/containers.conf` file.
__/etc/containers/containers.conf.d__ which will be loaded in alphanumeric order.
For user specific configuration it reads __\$XDG_CONFIG_HOME/containers/containers.conf__ and
If the `CONTAINERS_CONF` path environment variable is set, just
__\$XDG_CONFIG_HOME/containers/containers.conf.d/\*.conf__ files. When `$XDG_CONFIG_HOME` is not set it falls back to using `$HOME/.config` instead.
this path will be used. This is primarily used for testing.
Fields specified in the containers.conf file override the default options, as
Fields specified in a containers.conf file override the default options, as
well as options in previously read containers.conf files.
well as options in previously loaded containers.conf files.
**storage.conf**
**storage.conf**
The `/etc/containers/storage.conf` file is the default storage configuration file.
The `/etc/containers/storage.conf` file is the default storage configuration file.
Rootless users can override fields in the storage config by creating
Rootless users can override fields in the storage config by creating
`$HOME/.config/containers/storage.conf`.
__$HOME/.config/containers/storage.conf__.
If the `CONTAINERS_STORAGE_CONF` path environment variable is set, this path
If the `CONTAINERS_STORAGE_CONF` path environment variable is set, this path
is used for the storage.conf file rather than the default.
is used for the storage.conf file rather than the default.
