Azure Container Apps Security Limitations

The Anthropic secure-deployment guide recommends a set of Linux container security primitives. Most of them are not exposed by Azure Container Apps' management surface at any API version. This is verified, not suspected:

• azure-mgmt-appcontainers==4.0.0 Python SDK — Container.__init__ accepts only image, name, command, args, env, resources, volume_mounts, probes. No security_context, no ContainerSecurityContext model anywhere in the package.
• ARM Bicep template ref — Microsoft.App/containerApps@2026-01-01 — Container resource has no securityContext, runAsNonRoot, runAsUser, allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities, or seccompProfile. Consistent across every API version from 2022-03-01 through 2025-10-02-preview to 2026-01-01.
• Microsoft ACA Security Baseline (updated 2026-04-01) — documents network/identity/encryption controls only. Profile explicitly: Customer can access HOST / OS: No Access. Host security boundary is Microsoft-owned and not customer-tunable.

ACA is a serverless-ish platform; the design choice is that Microsoft owns the host kernel, capability set, and seccomp profile platform-wide. Customer security expression happens at the image layer + via the surfaces ACA does expose (VNet/NSG, ingress, identity, ACR).

Fundamental gaps vs. the Anthropic guide

Primitive	Why it matters	What HoloDeck does instead
runAsNonRoot=true	Refuses to start if the image runs as root	Image-layer enforcement — Dockerfile USER holodeck (UID 1000). Doesn't refuse-to-start guarantee, but the image cannot run as root by construction.
allowPrivilegeEscalation=false	Blocks setuid escalation paths	Platform default — ACA does not grant privileged mode at all. No customer-facing field to assert it, but the property holds.
capabilities.drop: [ALL]	Removes Linux capabilities like NET_ADMIN, SYS_ADMIN	Microsoft-controlled default cap set, not customer-tunable. If your threat model requires CAP_NET_RAW removal etc., move to AKS.
readOnlyRootFilesystem=true	Prevents writes to image FS	Image-layer approximation — chmod -R a-w on /app/data, /app/instructions. The rest of / is writable; this is genuinely weaker than the Kubernetes primitive.
seccomp profiles (custom)	Restricts available syscalls beyond Docker default	ACA uses the platform-default seccomp profile. Customer cannot supply one.
--userns-remap	Maps container UID 0 to unprivileged host UID	Not exposed. The non-root holodeck user (UID 1000) mitigates most of the risk; with no exposed UID 0 in the image, userns remap is mostly belt-and-suspenders.
--ipc private	Isolates SysV IPC namespaces	Not exposed. ACA replicas don't share an IPC namespace by default.
--pids-limit	Bounds fork bomb damage	Not exposed. The replica memory limit indirectly caps fork bomb impact (each forked process consumes RSS).
--network none + Unix socket proxy	Eliminates direct network egress	Use deployment.security_profile: hardened (P3, in progress) for the Envoy-sidecar equivalent.

Escape hatches

For threat models that genuinely require the primitives above, deploy to:

• AKS with Pod Security Standards (restricted profile). Full Kubernetes securityContext is available. HoloDeck doesn't ship an AKS deployer in v1, but the image generated by holodeck deploy build is unmodified — you can apply your own AKS manifest with the securityContext block populated.
• Self-hosted Kubernetes — same story.
• Modal / Fly Machines — per-session ephemeral containers; see spec 034 §"Out of scope for v1".

Why this isn't a HoloDeck bug

There is no holodeck deploy flag that can turn these on. The ACA ARM API doesn't accept the fields. We file no feature request because none of these primitives are on Microsoft's public roadmap for ACA — the microsoft/azure-container-apps GitHub has no active issue for securityContext support as of 2026-05-23.

If you need them, AKS (or a non-Azure runtime) is the right deployment target — not a different HoloDeck configuration.