Image files

Image files

Image files shows the files inside a container image, read straight from the registry the image comes from. Nothing runs in a container, nothing is pulled on a node and you need no local docker. It answers questions such as "what is really in this image?" or "which config file did the build put in /etc?".

Contents: Opening an image · What is shown · Which credentials are used · Where Sextant connects · Viewing and downloading a file · Limits · Cache · What it does not do

Opening an image

• From a container: in a Pod's details, each container's header has Browse image files. It opens the page on that container's image, and the pod's pull secrets are used if the registry needs them.
• From a reference: open Image files in the Workloads section (or find it in the command palette), type an image reference such as registry.example.com/team/app:1.0 and press Open.

Nothing is fetched until you press Open (or Open this image). Stop cancels the opening; Close image closes it. At most four images are open at once.

When the image is a multi-platform one, Platform lists the platforms it has and you pick one; the default is linux/amd64, otherwise the first.

What is shown

After the image is opened you see a summary: the image, its digest, the platform, the credentials that were used (Anonymous, Pull secret <name> or Your Docker credentials) and the number of files. Two tabs follow:

• Files: the merged file tree, as a container would see it. Layers are applied bottom to top as the OCI spec says, so a file deleted in an upper layer is gone, and a file replaced in an upper layer shows the upper one. Search by path finds paths that contain your text (up to 500 results). Selecting a file or a folder shows its path, type, size, mode, owner, modification time and the layer it comes from.
• Layers: every layer with its digest, size, number of files and the command that created it.

Symbolic links show their target and Go to the target follows them, but only inside the image: a link is never followed onto your computer, and one that leads nowhere in the image says so. Entries with unsafe or too long paths (for example with ..) are left out, and the summary counts them.

Which credentials are used

For each registry the first match wins; with none, access is anonymous:

1. From a pod: when you open the image from a Pod's container, the pod's imagePullSecrets, then its ServiceAccount's (kubernetes.io/dockerconfigjson and kubernetes.io/dockercfg Secrets). The match follows the kubelet: the registry host (and port) of the key, the Docker Hub aliases and *.domain wildcards.
2. Your Docker credentials, only if you opt in. The checkbox Use my Docker credentials for registries the pull secrets do not cover on the page is off by default. When on, Sextant reads ~/.docker/config.json (or $DOCKER_CONFIG/config.json) and uses, for that registry, credHelpers, then auths, then credsStore. A credential helper is a program you configured for exactly this; turning the option on lets Sextant run docker-credential-<name> (without a shell, with a clean environment, 10 seconds at most).

A reference you type uses anonymous access or, with the opt-in, your Docker credentials; pull secrets are used only when you open the image from a pod. Credentials stay in Sextant's backend: they never reach the window, a log, an error or the cache. The window only learns which source answered.

Where Sextant connects

The registry is the one named in the reference (docker.io is Docker Hub), so Sextant has to be careful where it connects:

• HTTPS only. There is no plain-HTTP and no "insecure registry" option, so a registry served over HTTP, or with a certificate your operating system does not trust, cannot be browsed.
• Refused addresses. Sextant never connects to this computer or to cloud metadata services: loopback (127.0.0.1, ::1, localhost, *.localhost), link-local (169.254.0.0/16, fe80::/10), unspecified and multicast addresses, the metadata addresses of AWS over IPv6 and Alibaba Cloud, and the IPv4-mapped and NAT64 forms of these. It checks IP addresses written in the reference and every address a name resolves to, and the same check covers the token server a registry names and every download redirect. Private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are allowed, because in-cluster and company registries live there. When you use a proxy (HTTPS_PROXY), the proxy resolves names, so only the check of the written address applies.
• Tokens and redirects. Sextant asks the registry's token server for a read-only (pull) token for the one repository, never a wider one. Layers are often kept on object storage; a redirect is followed (at most five, each HTTPS and checked) without sending any credential along. A registry can name the token server, and Sextant sends the credentials it holds for that registry to it, as Docker does.
• Every download is verified. Each layer is hashed while it is read and refused if its digest does not match the manifest.

Errors never contain a full URL, a token or a credential.

Viewing and downloading a file

• Text view: a text file shows its first 1 MiB. A file that is not UTF-8 text, or has a NUL byte at its start, is binary: Sextant does not show it and offers Download.
• Download: Download asks where to save the file in the system's save dialog. The data is written to a hidden temporary file next to the destination and moved into place only after the whole layer was read and its digest matched; a cancelled or failed download leaves nothing behind.

Both read the file's layer from the registry again and verify it before anything is shown or saved, so a small file at the beginning of a big layer still downloads the whole layer; the progress shows how much of it has been read. Nothing from an image is ever executed, and nothing is written to your disk except the file you download.

Limits

Limits protect you from huge or hostile images (compression bombs, millions of entries). The main ones:

• at most 128 layers; a layer up to 4 GiB compressed and 16 GiB unpacked; at most 8 GiB downloaded per opening;
• at most 300 000 entries in all layers; path names up to 4096 bytes;
• a folder lists up to 10 000 entries (the page says when the list is cut); a search returns up to 500 paths;
• a downloaded file up to 4 GiB;
• no data for 60 seconds, or 30 minutes for one opening, stops it with a timeout.

Cache

Sextant keeps the index of each verified layer (its list of files, not its contents) in the application's cache folder (image-files/), up to 64 MiB per layer and 256 MiB in all, the least recently used removed first. A layer you opened before shows from the cache in the progress and opens quickly. Manifests are not cached, because a tag can move to another image. Nothing from an image's files is cached. You can delete the image-files folder in the cache folder at any time (see Settings).

What it does not do

• It is a window feature: AI agents and extensions cannot browse images.
• It does not pull or run the image, and it does not show a Secret or anything of the cluster.
• Encrypted layers, non-distributable layers and Docker schema 1 manifests are refused.

Next: Using Sextant, Set image.