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) access**inside 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.

  • 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.

Would you like help setting up automated CVE scanning in your CI/CD pipeline? 🚀

Clone this wiki locally