AGENT SKILL

implementing-container-image-minimal-base-with-distroless

Reduces container attack surface by building application images on Google distroless base images that ship only the application runtime - no shell, package manager, or OS utilities - using multi-stage build patterns plus debugging and scanning techniques adapted to distroless. Use when hardening container images, cutting attack surface in a container architecture, or answering an assessment finding about bloated base images. Keywords: distroless, multi-stage build, no shell, nonroot tag, debug image, scratch, attack surface. Do not use for scanning an image for known CVEs - use scanning-docker-images-with-trivy.

License 许可
Apache-2.0
最近更新
2026-09-11
Stars
★ 0
Forks
0

01 前言 Front Matter

name
implementing-container-image-minimal-base-with-distroless
tags
[ "distroless", "container-images", "minimal-base", "attack-surface", "docker", "security-hardening", "supply-chain", "kubernetes" ]
author
mahipal
domain
cybersecurity
license
Apache-2.0
version
1.0
nist_csf
[ "PR.PS-01", "PR.IR-01", "ID.AM-08", "DE.CM-01" ]
subdomain
container-security
description
Reduces container attack surface by building application images on Google distroless base images that ship only the application runtime - no shell, package manager, or OS utilities - using multi-stage build patterns plus debugging and scanning techniques adapted to distroless. Use when hardening container images, cutting attack surface in a container architecture, or answering an assessment finding about bloated base images. Keywords: distroless, multi-stage build, no shell, nonroot tag, debug image, scratch, attack surface. Do not use for scanning an image for known CVEs - use scanning-docker-images-with-trivy.
mitre_attack
[ "T1610", "T1611", "T1609", "T1525", "T1195" ]

02 资源文件 7

03 SKILL.md 正文

Implementing Container Image Minimal Base with Distroless

Overview

Google distroless images contain only your application and its runtime dependencies, without package managers, shells, or other programs found in standard Linux distributions. By eliminating unnecessary OS components, distroless images achieve up to 95% reduction in attack surface compared to traditional base images like ubuntu or debian. Major projects including Kubernetes itself, Knative, and Tekton use distroless images in production. As of 2025, Docker also offers Hardened Images (DHI) as an open-source alternative for minimal container bases.

When to Use

  • When deploying or configuring implementing container image minimal base with distroless capabilities in your environment
  • When establishing security controls aligned to compliance requirements
  • When building or improving security architecture for this domain
  • When conducting security assessments that require this implementation

Prerequisites

  • Docker 20.10+ or compatible container build tool (Buildah, Kaniko)
  • Multi-stage Dockerfile knowledge
  • Application compiled as a static binary or with runtime bundled
  • Container registry for image storage

Available Distroless Images

Image Use Case Size
gcr.io/distroless/static-debian12 Statically compiled binaries (Go, Rust) ~2MB
gcr.io/distroless/base-debian12 Dynamically linked binaries needing glibc ~20MB
gcr.io/distroless/cc-debian12 C/C++ applications needing libstdc++ ~25MB
gcr.io/distroless/java21-debian12 Java 21 applications ~220MB
gcr.io/distroless/python3-debian12 Python 3 applications ~50MB
gcr.io/distroless/nodejs22-debian12 Node.js 22 applications ~130MB

Multi-Stage Build Patterns

Go Application

# Build stage
FROM golang:1.22-bookworm AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /server ./cmd/server

# Runtime stage - static distroless
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /server /server
USER nonroot:nonroot
ENTRYPOINT ["/server"]

Java Application

# Build stage
FROM maven:3.9-eclipse-temurin-21 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

# Runtime stage - Java distroless
FROM gcr.io/distroless/java21-debian12:nonroot
COPY --from=builder /app/target/app.jar /app.jar
USER nonroot:nonroot
ENTRYPOINT ["java", "-jar", "/app.jar"]

Python Application

# Build stage
FROM python:3.12-bookworm AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --target=/deps -r requirements.txt
COPY . .

# Runtime stage - Python distroless
FROM gcr.io/distroless/python3-debian12:nonroot
WORKDIR /app
COPY --from=builder /deps /deps
COPY --from=builder /app /app
ENV PYTHONPATH=/deps
USER nonroot:nonroot
ENTRYPOINT ["python3", "/app/main.py"]

Node.js Application

# Build stage
FROM node:22-bookworm AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .

# Runtime stage - Node distroless
FROM gcr.io/distroless/nodejs22-debian12:nonroot
WORKDIR /app
COPY --from=builder /app .
USER nonroot:nonroot
CMD ["server.js"]

Security Benefits

Attack Surface Comparison

Component Ubuntu Alpine Distroless
Shell (bash/sh) Yes Yes No
Package manager apt apk No
coreutils Full BusyBox No
curl/wget Yes Yes No
User management Yes Yes No
Known CVEs (typical) 50-200+ 5-20 0-5
Image size (base) ~77MB ~7MB ~2-20MB

Security Implications

  • No shell: Attackers cannot exec into containers to run commands
  • No package manager: Cannot install additional tools or malware
  • No coreutils: No cat, ls, find, curl for reconnaissance
  • Minimal CVEs: Fewer packages means fewer vulnerabilities to patch
  • Non-root by default: :nonroot tag runs as UID 65534

Debugging Distroless Containers

Since distroless has no shell, use these techniques for debugging:

Debug Image Variant

# Use debug variant in non-production environments only
FROM gcr.io/distroless/base-debian12:debug
# Includes busybox shell at /busybox/sh
# Exec into debug variant
kubectl exec -it pod-name -- /busybox/sh

Ephemeral Debug Containers (Kubernetes 1.25+)

# Attach a debug container with full tooling
kubectl debug -it pod-name --image=busybox:1.36 --target=app-container

Crane/Dive for Image Inspection

# Inspect image layers without running
crane export gcr.io/distroless/static-debian12 - | tar -tf - | head -50

# Analyze image layers
dive gcr.io/distroless/static-debian12

Image Scanning Results

Typical vulnerability comparison using Trivy:

# Scan Ubuntu-based image
trivy image myapp:ubuntu
# Result: 47 vulnerabilities (3 CRITICAL, 12 HIGH)

# Scan Distroless-based image
trivy image myapp:distroless
# Result: 2 vulnerabilities (0 CRITICAL, 0 HIGH)

References

04 同仓库更多 Skills

NeelakshSaxena
NeelakshSaxena/Vayu

runpodctl

Runpod CLI for managing GPU/CPU workloads from the terminal — pods, serverless endpoints, templates, network volumes, Hub deploys, models, SSH, and file transfer (send/receive). Use for terminal/CI/scripting, Hub browse/deploy, SSH setup, `doctor`, or when the Runpod MCP tools are not connected. For structured tool calls in an MCP-enabled session, prefer runpod-mcp.

★ 0
NeelakshSaxena
NeelakshSaxena/Vayu

runpod

Start here for any Runpod task — running GPU/CPU pods, deploying serverless endpoints, templates, network volumes, building images, or understanding how Runpod works. Routes to the right skill (runpod-mcp, runpodctl, flash, companion-clis, runpod-usage, runpod-templates, runpod-migrate) and indexes two dozen live-verified end-to-end examples (golden paths) — use it when the lane is unclear, and for any multi-step or provisioning task even when it is not.

★ 0
NeelakshSaxena
NeelakshSaxena/Vayu

runpod-usage

How Runpod works and how to work it — pods vs serverless, GPU/VRAM selection, storage, building a container, networking, plus the agentic pod development loop (provision → ssh-exec → set up → poll readiness) and on-pod install hygiene (uv/apt). Use to answer "how does X work", "which GPU", "how do I build a container", or "how do I stand up a workload on a pod". Guidance, not a tool — execute with runpodctl, runpod-mcp, or flash.

★ 0
NeelakshSaxena
NeelakshSaxena/Vayu

runpod-templates

Runpod's official prebuilt pod templates (ComfyUI, PyTorch, and others): what each image ships, which ports and paths it uses, how to pick one, how to pin a version, and what is missing on first boot. Use when a task says "run <X> on a pod" and an official template already covers it, instead of building an image — and when a user needs help with or wants to fix something about a Runpod template they are already running (won't boot, can't reach the UI, missing models, wrong CUDA line, broken ComfyUI workflow metadata on imported workflows): start here and route onward. Deploy with runpodctl or runpod-mcp; end-to-end walkthroughs live in the runpod router's golden paths.

★ 0
NeelakshSaxena
NeelakshSaxena/Vayu

runpod-migrate

Migrate a codebase from the Runpod GraphQL API or REST v1 to REST v2 — inventory which parts use which API version, rewrite the call sites, flag breaking changes, and verify. Use when someone asks to move to v2, asks what v2 would change, or asks which Runpod API their code is on. For managing infrastructure rather than migrating code, use runpod-mcp or runpodctl.

★ 0
NeelakshSaxena
NeelakshSaxena/Vayu

runpod-mcp

Manage Runpod infrastructure — pods, serverless endpoints, jobs, templates, network volumes, container-registry auth, GPU/CPU catalog, and billing — via the Runpod MCP server's structured tool calls. Use when the Runpod MCP tools (create-pod, list-endpoints, …) are connected in this session, or to connect them (hosted OAuth or local npx). Prefer this over runpodctl for plain infra CRUD when MCP is available; use runpodctl for the terminal, file transfer, or SSH setup.

★ 0