Security context

This page describes the Kubernetes security posture of an ArconQ 1.2.0 installation: how the pods that make up ArconQ are configured, what they are allowed to do on the cluster, and — just as importantly — what they are not allowed to do.

ArconQ follows a least-privilege, defense-in-depth model. Every pod the chart deploys runs as a non-root user with a hardened security context and Kubernetes API access is granted only where a component genuinely needs it.

note

The values described here are the defaults shipped with the ArconQ Helm chart. They are applied consistently through shared chart helpers, so every workload inherits the same baseline unless a specific component requires a different, documented value.

Baseline pod hardening

Every ArconQ pod is created with the following pod-level security context:

Setting	Value	Effect
runAsNonRoot	true	The kubelet refuses to start the pod if any container image would run as root (UID 0).
runAsUser / runAsGroup	non-zero UID/GID	Containers run as an unprivileged, dedicated user.
fsGroup	matches the UID	Mounted volumes are owned by the workload's group, so it can read and write its own data.
fsGroupChangePolicy	OnRootMismatch	Volume ownership is only re-chowned when the top-level permissions differ, avoiding slow recursive permission changes on large volumes.
seccompProfile.type	RuntimeDefault	The container runtime's default seccomp filter is applied, blocking dangerous syscalls.

On top of that, every container is configured with:

Setting	Value	Effect
runAsNonRoot	true	Reinforces the non-root requirement at the container level.
privileged	false	Containers never run in privileged mode and cannot access host devices.
allowPrivilegeEscalation	false	A process can never gain more privileges than it started with (e.g. via setuid binaries).
capabilities.drop	["ALL"]	All Linux capabilities are dropped. No capability is added back.

What this means in practice

Because of the baseline above, ArconQ pods cannot:

• run as the root user;
• gain additional privileges at runtime (no privilege escalation, no setuid);
• use any Linux capability (e.g. NET_ADMIN, SYS_ADMIN, NET_RAW, CHOWN, …) — all are dropped;
• run in privileged mode or access host devices;
• bypass the runtime's default seccomp syscall filter.

These restrictions also apply to init containers (such as the wait-for-… dependency checks that run before the main containers start) and to the chart's Jobs and hooks.

User applications

Applications you deploy through ArconQ are the workloads most exposed to your own code, so they are the most tightly constrained:

• They run as the dedicated arconq user with ID 58360 (non-root) and the same group ID, with the same baseline hardening described above (no privilege escalation, all capabilities dropped, RuntimeDefault seccomp).
• They are assigned the arq-app-sa service account, which has no RBAC permissions at all and has service-account-token automounting disabled. As a result, an application cannot talk to the Kubernetes API — there is no mounted token to authenticate with, and even if one were present it would carry no permissions.
• Because applications are non-root, they cannot bind to privileged ports (below 1024). This is why, since 1.2.0, Debug Mode SSH listens on port 2222 instead of 22. See the 1.2.0 migration guide and Debug Mode.
• Files written by applications on app shared storage are owned by user arconq (58360:58360). (Installations upgrading from versions prior to 1.2.0, where app files were owned by root, must re-own those files — see the migration guide.)