Security and isolation

How alawadi.cloud isolates every project and runs every app unprivileged, enforced at admission, so a root or privileged image cannot run.

Tenant isolation

Each project runs in its own isolated namespace with a private network. By default nothing outside the project can reach your services, and your services cannot reach another tenant. Every project is created with a default-deny network policy, resource quotas, and scoped access already applied. You do not configure any of this.

Unprivileged by default

Every container app runs locked down. You do not opt in, and you cannot opt out:

Non-root only. A container that tries to run as root will not start. Add a non-root USER to your Dockerfile (see Container image requirements).
No privileged mode and no privilege escalation.
No host access. No host network, host PID, host filesystem, or hostPath mounts, and no Docker socket.
All Linux capabilities dropped, with the RuntimeDefault seccomp profile.
Read-only root filesystem. Write temporary files to /tmp.

These are the controls of the Kubernetes restricted Pod Security Standard. It is enforced at admission on every tenant namespace, and an independent policy layer continuously re-checks the same standard against every running workload. A root or privileged image is rejected before it can run, on more than one layer.

Defense in depth

Enforcement does not rely on a single setting. The restricted standard is applied per namespace and verified again, independently, across all tenant workloads, so a misconfiguration in one layer cannot quietly let a privileged container through.

Image supply chain

Images are pulled from your private registry on the platform.
Deploys reference an immutable tag (never :latest) and are authorized by short-lived GitHub OIDC tokens, so there are no long-lived secrets in your pipeline. See Deploy from GitHub via OIDC.
Image source is governed at admission, so only images you own and pushed through your own pipeline run in your project.

Secrets and connections

Managed database credentials are injected into your app as environment variables backed by Kubernetes secret references. The password is never shown in the dashboard or in logs.
Public apps receive managed TLS automatically on their *.alawadi.cloud hostname and on any custom domain you add.

What this means for your image

Build a small, non-root image that listens on 8080 and writes only to /tmp. The portal generates a production-ready Dockerfile and CI workflow that already satisfy every rule above, so you rarely set these by hand. See Container image requirements for the full checklist.