Glossary

• Fully rootless

  • Fully rootless means that a Docker image can be built, executed, and run without requiring root (privileged) accessinside the container or on the host system. This is particularly important for security, as running processes as root inside a container can pose security risks if the container is compromised.
  • A fully rootless Docker image implies:

    1. No root user inside the container:

       • The container does not run as root by default.
       • Instead, it runs as an unprivileged user (e.g., UID 1000 or nobody).

    2. No root access required to build/run the container:

       • The image can be built and run without requiring root privileges on the host.
       • Typically used with Rootless Docker, which allows running containers without root privileges.

    3. No setuid binaries or privileged operations:

       • The image does not include binaries or operations that require elevated privileges (e.g., sudo, setcap, chown root).

    4. Complies with container security best practices:

       • Useful for environments like Kubernetes or Podman, where security policies (e.g., OpenShift's SCC) prevent running as root.

• APKO Security

Security Feature	How Apko Ensures Security 🛡️
Reproducible Builds 🔄	Apko ensures deterministic builds, meaning the same input always produces the same output, reducing the risk of supply chain attacks.
No Root by Default ❌👑	Apko-built images do not run as root unless explicitly configured, reducing the attack surface.
Minimal Base Image 🏗️	Uses a tiny, immutable base (often wolfi or alpine) with only required dependencies, reducing vulnerabilities.
Immutable Package Installation 🔒	Packages are version-locked, meaning no unexpected updates or changes that could introduce vulnerabilities.
Snapshot-Based Package Repositories 📌	Uses fixed repository snapshots (e.g., snapshot.alpinelinux.org), preventing package version drift or supply chain attacks.
No Layer Caching Issues 🚫🗂️	Unlike Docker, Apko does not use cached layers that may introduce outdated or vulnerable dependencies.
Cryptographic Signing of Packages ✍️🔑	Uses Melange to sign built APKs, ensuring integrity and authenticity of installed packages.
Minimal Attack Surface 🎯	Apko removes unnecessary files, binaries, and utilities (e.g., no shell unless required) to reduce exploitability.
SBOM Generation (Software Bill of Materials) 📜	Automatically generates SBOM metadata, allowing easy vulnerability tracking and compliance audits.
No External Package Fetching During Build 🚫🌍	Unlike Docker’s apk add, Apko resolves and locks package versions upfront, avoiding MITM or poisoned package attacks.
Content Addressable Storage (CAS) 📦	Uses CAS to ensure identical image builds, preventing unverified dependencies or build inconsistencies.
Read-Only File System Support 🔐	Apko-built images can be configured as read-only, preventing modifications at runtime.
No SetUID Binaries ❌🔼	By default, Apko excludes setuid binaries, reducing privilege escalation risks.
Built-in Package Verification ✅	Ensures that all installed packages come from trusted, signed sources.
Works with Rootless Runtimes 🏃‍♂️	Fully compatible with rootless container runtimes like Podman, reducing host privilege exposure.
Strict Dependency Resolution 🧩	Only includes explicitly defined dependencies, minimizing attack surface from unused libraries.
Transparent Build Logs 🔍	Ensures all build steps are deterministic and traceable, useful for audits and debugging.

💡 Conclusion: Apko prioritizes security, immutability, and reproducibility, making it safer than traditional Docker builds. 🚀 Would you like an example security-hardened Apko configuration?