Skip to content

Glossary

Jump to bottom
SMART2016 edited this page Mar 19, 2025 · 8 revisions

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).
  1. 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.
  1. No setuid binaries or privileged operations:
  • The image does not include binaries or operations that require elevated privileges (e.g., sudo, setcap, chown root).
  1. 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.

CVE

What is CVE in Respect to Containers?

CVE (Common Vulnerabilities and Exposures) is a publicly disclosed security vulnerability identifier. When discussing containers, a CVE refers to known security vulnerabilities in container images, software packages, or underlying dependencies.

Each CVE:

  • Has a unique identifier (e.g., CVE-2023-12345).
  • Describes a specific security flaw in software.
  • Is scored based on severity using CVSS (Common Vulnerability Scoring System).
  • Helps teams identify and patch security issues in containerized applications.

1️⃣ How CVEs Affect Containers

Containers are built from layers of software (OS, libraries, and applications). Any vulnerable package inside a container can introduce security risks.

🔹 Types of CVEs in Containers:

CVE Type Example Impact
Base Image Vulnerabilities Outdated OS packages (e.g., glibc, openssl).
Application Library Flaws CVEs in dependencies (e.g., Python, Node.js libraries).
Kernel Exploits Vulnerabilities in the container’s runtime (e.g., Docker, Kubernetes).
Configuration Issues Privilege escalation due to insecure settings (e.g., running as root).

2️⃣ Example of a CVE in a Container

Imagine you are using an Alpine Linux-based container:

FROM alpine:3.14
RUN apk add --no-cache openssl

If openssl in Alpine 3.14 has a known vulnerability, a security scanner may report:

CVE-2023-12345 (HIGH): OpenSSL buffer overflow vulnerability
Affected package: openssl-1.1.1n-r0
Fixed in: openssl-1.1.1p-r0

✅ Solution: Upgrade the package:

FROM alpine:3.18
RUN apk add --no-cache openssl=1.1.1p-r0

3️⃣ How to Detect CVEs in Containers

Use container security scanners to find vulnerabilities.

🔍 Scan with Trivy (Recommended)

trivy image my-container:latest

📌 Output Example:

+---------+------------------+----------+-------------------+---------------+
| PACKAGE | VERSION          | SEVERITY | CVE ID            | FIXED VERSION |
+---------+------------------+----------+-------------------+---------------+
| openssl | 1.1.1n-r0        | HIGH     | CVE-2023-12345    | 1.1.1p-r0     |
+---------+------------------+----------+-------------------+---------------+

🔍 Scan with Syft & Grype

syft my-container:latest -o json | grype

✅ **Automates CVE scanning in CI/CD pipelines.

4️⃣ How to Fix CVEs in Containers

Fix Strategy How to Apply
Upgrade the base image Use newer versions (e.g., FROM alpine:3.18 instead of 3.14).
Update affected packages Explicitly install fixed versions (e.g., apk add openssl=1.1.1p-r0).
Use minimal images Use distroless or scratch images to reduce attack surface.
Remove unused dependencies Avoid installing unnecessary packages (e.g., apk add curl when not needed).

5️⃣ Preventing CVEs in Containers

🚀 Best Practices to Reduce Vulnerabilities:

  • 🛠️ Use smaller, security-focused images (distroless, wolfi).
  • 🔄 Regularly scan and update images in CI/CD.
  • 🏗️ Use SBOMs (Software Bill of Materials) to track dependencies.
  • 📜 Enable automated vulnerability alerts in Kubernetes (KubeClarity, Trivy Operator).

6️⃣ Final Thoughts

  • CVE is a security vulnerability that may exist in your container's base OS, application, or dependencies.
  • Scanning tools (Trivy, Grype) help detect and fix CVEs before deploying containers.
  • Best practices include using minimal images, updating dependencies, and automating security scans.

Distroless Containers

What is Distroless in Containers?

Distroless refers to a container image that does not include a traditional Linux distribution like Debian, Ubuntu, or Alpine. Instead, it contains only the necessary application runtime and dependencies, without extra tools like package managers, shells, or utilities.

🚀 Distroless images are minimal, more secure, and optimized for production.

1️⃣ Why Use Distroless Containers?

Distroless images remove unnecessary components, reducing the attack surface and improving security.

🔍 Key Benefits:

Feature Traditional Images Distroless Images
Size Large (100MB+) Small (10-30MB)
Security High risk (contains shells, package managers) Low risk (no shell, no package manager)
Attack Surface More tools → More vulnerabilities Minimal tools → Less risk
Compliance Harder to lock down Easier to meet security policies
Performance More overhead Faster startup

💡 Example: A distroless image removes package managers (apt, yum), shells (bash), and unnecessary binaries, reducing potential exploits.

2️⃣ How is Distroless Different from Alpine?

Alpine is small (5MB) but still includes package managers (apk), shells, and extra utilities.
Distroless removes everything unnecessary, making it even more secure.

Feature Alpine Linux Distroless
Base OS Yes (musl libc) No OS components
Shell (sh, bash) ✅ Yes ❌ No
Package Manager ✅ Yes (apk) ❌ No
Security 🔸 Good ✅ Best

📌 Distroless is ideal for production when you don’t need a shell or package manager inside the container.

3️⃣ Example: Using a Distroless Container

Instead of a Debian-based image, use Distroless.

🔴 Traditional Image (Debian)

FROM debian:latest
WORKDIR /app
COPY myapp .
CMD ["./myapp"]

❌ Issues:

  • Contains bash, apt, wget, and other unnecessary tools.
  • Larger attack surface.

✅ Distroless Image

FROM gcr.io/distroless/static:nonroot
WORKDIR /app
COPY myapp .
USER nonroot
CMD ["./myapp"]

✅ Advantages:

  • No shell (bash, sh removed).
  • No package manager (apt, apk removed).
  • Smaller, more secure, and production-ready.

4️⃣ Types of Distroless Images

Distroless images are available in different variants:

Variant Best for
distroless/static:nonroot Static binaries (Go, Rust, C++)
distroless/base Applications requiring minimal libraries
distroless/java Java applications
distroless/python Python applications

✅ Choose the right distroless image for your application’s runtime.

5️⃣ When Should You Use Distroless?

✔ Best for:

  • Production workloads (secure by default).
  • Microservices that don’t need a shell.
  • High-security environments (less attack surface).
  • CI/CD deployments with automated builds.

❌ Not ideal for:

  • Debugging (no shell, no package manager).
  • Development environments where package installation is needed.

💡 Tip: For debugging, you can temporarily use a debug version of Distroless:

docker run -it --entrypoint=/bin/sh gcr.io/distroless/base:debug

6️⃣ Conclusion

✔ Distroless containers are minimal, secure, and production-ready.
✔ They remove unnecessary tools like shells and package managers, reducing attack surfaces.
✔ Ideal for microservices, CI/CD, and secure containerized apps.

Clone this wiki locally