QuantyKube

ADR-025 Pulls go through the import

All pages

ADR-025, from docs/DECISIONS.md in the QuantyKube repository.

Status In force

PullImage fetches an image over the OCI distribution API (src/registry.rs): the manifest or index by tag or digest, an index resolved to linux/amd64, a Bearer token fetched anonymously when the registry challenges for one, and blobs followed through the redirects registries use to send them to a storage host, which never gets the registry's token. What it fetches is written as an OCI image layout and imported from there (ADR-017), so a digest is checked in exactly one place whichever way an image arrives, and a registry that serves the wrong bytes produces an error, not an image. References are read the way Docker reads them: busybox is docker.io/library/busybox:latest.

HTTP goes through QuantyCore's HTTP/1.1 client and HTTPS through its TLS, which is unreviewed (QuantyCore ADR-003), against the system's root certificates. Behind a proxy, HTTPS is tunnelled with CONNECT through the proxy HTTPS_PROXY names, except for hosts in NO_PROXY, the way containerd and most other clients read them. Registries named with --plain-http are reached without TLS, as a local registry in an air gapped network often is. A test pulls through a CONNECT proxy from a registry whose certificate comes from a CA made for the test, and is refused when that CA is not trusted; by hand, the same binary pulls from GCR, registry.k8s.io, GHCR and Quay through an intercepting proxy.

Credentials from an image pull secret are sent only to the token endpoint, as HTTP Basic, or to a registry that asks for Basic itself; a token issued by the registry is used as it is. They never follow a redirect to another host.

The cost: the registry and the proxy are trusted with whatever TLS does not catch until the TLS has been reviewed; identity tokens, which need an OAuth2 exchange, are refused; and plain HTTP is never sent through the proxy.