Terminal sessions

The Terminal button on a container instance's Components tab opens an interactive shell in one of its pods. This page is for the people who run the platform: where those sessions live, what limits them and what is kept about them.

Where a session runs

The portal holds the session open over a live connection to the platform API, /hubs/crates. The platform API checks kernel/crates/exec on the boundary — a role assigned only on the resource group or the instance does not satisfy it — then containerinstance/exec on the instance, checks that the pod belongs to it, and starts /bin/sh in the chosen container through the Kubernetes API, as the platform's own service account. Keystrokes and output flow through the platform API for as long as the session lasts.

Sessions are held in the platform API's memory. A session ends when the user closes the terminal, when the shell exits, when the user's connection to the platform API drops, or when the platform API restarts.

Limits

• Five open sessions per user, across every instance on the platform. A further session is refused with Unable to open terminal: User … is at the concurrent terminal session cap (5). The number is the platform API's Crates:MaxConcurrentSessionsPerUser setting; the installer does not set it, so the default of five applies.
• No idle timeout. A session is not closed for inactivity. The Crates:IdleTimeout setting (five minutes) is read only by the separate Crates service, which holds no terminal sessions, so it has no effect on them.

What is recorded

Today the platform keeps no record of terminal sessions:

• Opening and closing a session writes nothing to the instance's Activity log.
• Every line typed is passed through a redaction step that masks passwords and tokens, and is then dropped. For each dropped line the platform API logs the warning Crate command audit row dropped (session …, seq …) — no durable writer configured in this host., without the command.

Treat containerinstance/exec accordingly: a shell in a pod reads everything the workload can, vault secrets included, and nothing records what was done with it. The built-in roles that hold it are Owner, Contributor and Blueprints Operator, and Platform Owner and Platform Contributor on every boundary. Changes to files on persistent volumes made through the Files tab, by contrast, are recorded in the Activity log.

Caution

A shell does not need the portal's terminal. Owner, Contributor, Platform Owner, Platform Contributor, Blueprints Operator and Apps Operator also hold Kubernetes pods/exec in the resource group's namespace, where container instances run next to apps. Anyone in those roles with direct cluster access can kubectl exec into an instance's containers — Apps Operator included, although it has no containerinstance/exec — and read the vault secrets in /secrets/env.json. Such a session goes through the Kubernetes API with the person's own credentials, not through the platform API, so none of the checks or limits above apply to it.