Add support for privileged container mode #74
Description
Is your feature request related to a problem? Please describe.
I'm trying to run a Gitea Actions runner (act_runner) with Docker-in-Docker (DinD) to execute CI/CD workflows with proper job isolation. The runner needs to start a Docker daemon inside its container, which requires privileged security context in Kubernetes. Currently, QuickStack does not expose a way to set securityContext.privileged: true on a container, making it impossible to run DinD workloads.
Describe the solution you'd like
A toggle in the app settings (e.g. in the Advanced tab) to enable privileged mode for a container. This would set securityContext.privileged: true on the Kubernetes pod spec. A simple checkbox labeled "Run as privileged container" with a warning about the security implications would be sufficient.
Describe alternatives you've considered
- Host mode runner (no Docker): Running act_runner with
hostlabels so jobs execute directly in the runner container without isolation. This works but requires all build tools to be
pre-installed in the image and provides no isolation between jobs. - fuse-overlayfs + --bridge=none: Starting dockerd with unprivileged-compatible storage drivers and disabled networking. The storage driver works, but Docker still fails at
unshare
when pulling/extracting image layers due to missing permissions. - Patching the deployment via kubectl: Manually running
kubectl patch deploymenton the server to inject the privileged security context. This works but is fragile and gets overwritten
on every QuickStack redeploy.
Additional context
This is a common requirement for any workload that needs Docker-in-Docker, such as CI/CD runners (Gitea Actions, GitLab Runner, Jenkins agents), container image builds, or GPU workloads. The privileged flag is a standard Kubernetes feature and many self-hosting platforms (Portainer, Coolify) expose it in their UI.