Container Security

  4 minute read  

By default, a container on a Trustgrid appliance runs with safe, restrictive settings — it can’t see the host filesystem, can’t touch host devices, and can’t interfere with the appliance or other containers. The toggles on this page let you grant additional access when a specific workload needs it.

User

The User field on the Overview screen sets which user inside the container runs the application. By default it uses the user the image was built to run as.

When to set it:

  • The image runs as root by default and you want it to run as a specific UID instead — usually for ownership of files in a mounted volume.
  • Several containers share a volume and need to agree on the same UID so they can all read/write the files.
  • You have a compliance requirement that nothing runs as UID 0.

Accepted formats: user, user:group, uid, uid:gid, or a mix.

Linux Capabilities

The Linux Capabilities screen lets you grant the container specific abilities it doesn’t have by default, or remove abilities it does have.

You only need to touch this if your image’s documentation says it requires a specific capability — for example “requires NET_ADMIN” or “needs SYS_PTRACE.”

Examples of when an image might ask for one:

CapabilityTypical use
CAP_NET_BIND_SERVICEListen on a privileged port (under 1024) without running as root.
CAP_NET_ADMINManage network interfaces or routing inside the container — VPN clients, packet capture tools.
CAP_SYS_PTRACEAttach a debugger or strace to a process inside the container.
CAP_NET_RAWUse raw sockets — ping, traceroute, custom network tools.

Adding a specific capability is preferred over enabling Privileged — it follows the principle of least access.

Privileged

The Privileged toggle on the Overview screen grants the container elevated access at the container level. It’s commonly needed for workloads that manage kernel-level state, run a nested container runtime, or otherwise need more access than a specific Linux Capability can grant. Most container deployments do not require it. Where possible, use Linux Capabilities instead — granting only the specific capability a workload needs follows the principle of least access.

Use Init

The Use Init toggle on the Overview helps containers shut down cleanly.

A typical case: an application launched through a shell script wrapper (e.g. start.sh that runs java -jar app.jar). When you click Stop, the shutdown signal goes to the shell instead of the application — so the application keeps running until it’s force-killed after the Stop Time grace period. Use Init forwards the signal correctly so the application shuts down as expected.

It’s cheap to turn on and a safe default for any container whose entrypoint isn’t the application itself.

Require Connectivity

Require Connectivity will prevent containers with encrypted volumes from starting until they can reach the control plane.

Pair it with encrypted volumes so startup waits until the appliance can reach the Trustgrid control plane and unlock the volume. It only affects startup; a container that’s already running keeps running if the appliance disconnects from the control plane.

Save Output

The Save Output toggle on the Overview saves the container’s log output (everything it prints to the terminal) to the Trustgrid portal, where you can download it later from Compute → Output Artifacts at node scope — even after the container restarts.

Be careful what you save. If your container prints API keys, customer information, or other sensitive data, that ends up in Trustgrid’s log store. It is the customer’s responsibility to ensure no sensitive information appears in the output.

If you’re unsure about a container’s output, leave Save Output off and use the Logs viewer for live debugging instead — that shows logs as they happen without keeping a copy.

A secure setup for an internet-facing service

If you want a starting point for a service that’s exposed to the public internet:

  1. Set User to a non-root user (or use an image that already does).
  2. Leave Privileged off.
  3. Leave Linux Capabilities at defaults unless the image asks for one.
  4. Enable Use Init.
  5. Leave Save Output off unless you’ve checked the container’s output for sensitive data.
  6. Use encrypted volumes for application data.
  7. Add a Health Check so the container is flagged in the portal if it stops responding.