@ -61,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! -->
## Supported transports and their scopes
See containers-transports(5) for general documentation about the transports and their reference syntax.
### `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_]]],
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.
*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.
### `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:`
The `dir:` transport refers to images stored in local directories.
@ -80,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
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 `""`,
*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.
### `docker:`
@ -93,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`).
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)
or a wildcarded expression for matching all subdomains. For wildcarded subdomain
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.
### `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.
### `oci:`
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
a directory containing one or more tags, or any of the parent directories.
Supported scopes are paths to directories
(either containing an OCI layout, or subdirectories possibly containing OCI layout directories).
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.
*Note:* See `dir:` above for semantics and restrictions on the directory paths, they apply to `oci:` equivalently.
### `oci-archive:`
### `tarball:`
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`:
Supported scopes have the form _repo-path_`:`_image-scope_; _repo_path_ is the path to the OSTree repository.
The `tarball:` transport refers to tarred up container root filesystems.
_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.
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**=""
Path of imagestore different from `graphroot`, by default storage library stores all images in `graphroot` but if `imagestore` is provided it will store newly pulled images in provided `imagestore` but will keep using `graphroot` for everything else. If user is using `overlay` driver then images which were already part of `graphroot` will still be accessible ( Internally storage library will mount`graphroot` as an `additionalImageStore` to allow this behaviour ).
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 this field is for the users who want to split the file-system in different parts i.e disk which stores images vs disk used by the container created by the image.
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**=""
container storage run dir (default: "/run/containers/storage")
@ -104,6 +106,10 @@ containers/storage supports three keys
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 the 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.
@ -38,10 +40,13 @@ 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).
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.
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).
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`.
@ -54,7 +59,7 @@ Alternatively, for reading archives, @_source-index_ is a zero-based index in ar
(to access untagged images).
If neither _docker-reference_ nor @_source_index is specified when reading an archive, the archive must contain exactly one image.
It is further possible to copy data to stdin by specifying `docker-archive:/dev/stdin` but note that the used file must be seekable.
The _path_ can refer to a stream, e.g. `docker-archive:/dev/stdin`.
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 `$HOME` allow for overriding those in `/etc` and `/usr/share`. Modules in `$HOME` (or `$XDG_CONFIG_HOME` if specified) are only used for rootless users.
## 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}]
modules3.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
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
@ -151,7 +185,7 @@ A list of dns servers to override the DNS configuration passed to the
container. The special value “none” can be specified to disable creation of
Environment variable list for the container process, used for passing
environment variables to the container.
@ -185,6 +219,10 @@ Run an init inside the container that forwards signals and reaps processes.
**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
within containers. Note that the container-init binary will only be used when
the `--init` for podman-create and podman-run is set.
@ -229,6 +267,13 @@ 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.
**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.
@ -262,6 +307,12 @@ 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.
**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.
@ -417,11 +468,39 @@ The `engine` table contains configuration options used to set up container engin
Name of destination for accessing the Podman service. See SERVICE DESTINATION TABLE below.
**add_compression**=[]
List of compression algorithms. If set makes sure that requested compression variant
for each platform is added to the manifest list keeping original instance intact in
the same manifest list on every `manifest push`. Supported values are (`gzip`, `zstd` and `zstd:chunked`).
Note: This is different from `compression_format` which allows users to select a default
compression format for `push` and `manifest push`, while `add_compression` is limited to
`manifest push` and allows users to append new instances to manifest list with specified compression
algorithms in `add_compression` for each platform.
**cgroup_manager**="systemd"
The cgroup management implementation used for the runtime. Supports `cgroupfs`
and `systemd`.
**compat_api_enforce_docker_hub**=true
Enforce using docker.io for completing short names in Podman's compatibility
REST API. Note that this will ignore unqualified-search-registries and
short-name aliases defined in containers-registries.conf(5).
**compose_providers**=[]
Specify one or more external providers for the compose command. The first
found provider is used for execution. Can be an absolute and relative path or
a (file) name.
**compose_warning_logs**=true
Emit logs on each invocation of the compose command indicating that an external
compose provider is being executed.
**conmon_env_vars**=[]
Environment variables to pass into Conmon.
@ -446,10 +525,13 @@ conmon_path=[
]
```
**database_backend**="boltdb"
**database_backend**=""
The database backend of Podman. Supported values are "boltdb" (default) and
"sqlite". Please run `podman-system-reset` prior to changing the database
The database backend of Podman. Supported values are "" (default), "boltdb"
and "sqlite". An empty value means it will check whenever a boltdb already
exists and use it when it does, otherwise it will use sqlite as default
(e.g. new installs). This allows for backwards compatibility with older versions.
Please run `podman-system-reset` prior to changing the database
backend of an existing deployment, to make sure Podman can operate correctly.
**detach_keys**="ctrl-p,ctrl-q"
@ -510,6 +592,17 @@ with detailed information about the container. Set to false by default.
@ -820,6 +917,17 @@ 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`.
## 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.
# FILES
**containers.conf**
@ -832,15 +940,6 @@ __/etc/containers/containers.conf.d__ which will be loaded in alphanumeric order
Rootless users can further override fields in the config by creating a config
file stored in the __$HOME/.config/containers/containers.conf__ file or __.conf__ files in __$HOME/.config/containers/containers.conf.d__.
If the `CONTAINERS_CONF` environment variable is set, all system and user
config files are ignored and only the specified config file will be loaded.
If the `CONTAINERS_CONF_OVERRIDE` path environment variable is set, the config
file will be loaded last even when `CONTAINERS_CONF` is set.
The values of both environment variables may be absolute or relative paths, for
MSVSphere Packaging Team
5 months ago