Extend the built-in policy to validate signed moby/buildkit release and
floating tags before docker-container builders are created.
Pull the image first, inspect it through Docker, and bind verification to the
descriptor digest. Resolve signature attestations through the BuildKit API
embedded in the Docker daemon.
If pulling fails, use a local image while applying the same verification when
the containerd image store exposes an immutable descriptor. Keep the classic
image-store behavior unchanged because no descriptor is available.
Allow unmanaged repositories and digest-only references unchanged. Add the
allow-untrusted-image driver option as an explicit verification bypass.
Document the behavior and add policy, digest-pinning, and local fallback
coverage.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Allows using `--debug` to enable debug logging under
any subcommand. Currently it needed to be set as
`docker --debug buildx` meaning only way to enable debug
in standalone mode was to set env variable instead and
updating existing commands to add `--debug` was cumbersome.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Previously, the help information for buildx indicated that users could
create a new instance of the docker driver - which is explicitly
something we don't support, driver of this form are automatically
derived from the available list of docker contexts.
This patch ensures that don't have AllowsInstance set will not appear in
the help text, and additionally provide a new more specific error
message instead of the generic "failed to find driver". This should help
point users in the correct direction.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Kubernetes added the official `securityContext.seccompProfile` support in Kubernetes 1.19.
Seccomp is still disabled by default.
The legacy `container.seccomp.security.alpha.kubernetes.io/<PODNAME>` annotation has been deprecated and will be unsupported in Kubernetes 1.25.
https://kubernetes.io/docs/tutorials/security/seccomp/
A test cluster can be created with the following minikube command:
```
minikube start --feature-gates SeccompDefault=true --extra-config kubelet.seccomp-default=true
```
Related to moby/buildkit PR 2782
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This allows the parent cgroup to be customised, which allows resource
limits to be imposed on build containers separately from "user"
containers.
Signed-off-by: David Scott <dave@recoil.org>
- ./_site/engine/reference/commandline/buildx_build/index.html
* linking to internal hash #--buildkitd-flags-flags that does not exist (line 904)
<a href="/engine/reference/commandline/buildx_create/#--buildkitd-flags-flags"></a>
- ./_site/engine/reference/commandline/buildx_create/index.html
* linking to internal hash #--buildkitd-flags-flags that does not exist (line 350)
<a href="#--buildkitd-flags-flags"></a>
* linking to internal hash #--config-file that does not exist (line 336)
<a href="#--config-file"></a>
* linking to internal hash #--config-file that does not exist (line 336)
<a href="/engine/reference/commandline/buildx_build/#--load"></a>
* linking to internal hash #--load that does not exist (line 369)
<a href="/engine/reference/commandline/buildx_build/#--load"></a>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Put the flag descriptions/examples under an "examples"
section (used at docs.docker.com), and rephrase the
headings to be more consistent with other pages in the
docker documentation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the usage output of `--help` for each subcommand, to make
sure all flags/options are included on the page, and to make
it easier to keep docs in sync.
Note that the usage output is only used when reading these
docs on GitHub; docs.docker.com only consumes the "description"
and "example" sections (when present), and generates flag information
and usage output from source
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Tonis Tiigi