Chainguard Images

chainctl is a command-line interface (CLI) designed to provide comprehensive control over Chainguard resources. It is intended for automation and advanced operations that go beyond the capabilities of the Chainguard Console, making it suitable for DevOps workflows and CI/CD integration.

Key capabilities include managing:

• Container images
• Identity management
• Security configurations

Chainguard Containers are designed for secure software supply chains with the following features:

• Minimal design: No unnecessary software bloat.
• Daily builds: Ensures images are up-to-date with the latest security patches.
• High-quality SBOMs: Build-time Software Bill of Materials (SBOMs) attest to the provenance of all artifacts.
• Verifiable signatures: Provided by Sigstore.
• Reproducible builds: Achieved using Cosign and apko.

Chainguard provides two variations of the busybox image depending on the required C library (libc) dependency:

• latest: Use this variant for binaries that depend on musl.
• latest-glibc: Use this variant for binaries that depend on glibc.

Note: As of July 15, 2024, the :latest tag transitioned from an Alpine base to a Wolfi base. The :latest-glibc tag can be used to test the glibc-based Wolfi image before the transition.

# Test musl variant
docker run -it cgr.dev/chainguard/busybox:latest echo hello world!

# Test glibc variant
docker run -it cgr.dev/chainguard/busybox:latest-glibc echo hello world!

Chainguard's .NET SDK images currently provide 1xx feature bands exclusively (e.g., 9.0.109).

While Microsoft tags their SDK images with the version of the most recent feature band (e.g., 9.0.304), Chainguard's dotnet-sdk image is currently limited to the 1xx band due to technical and versioning complexities. We are working toward supporting additional feature bands in the future.

Chainguard provides two main types of container images to balance security and usability:

1. Production Images (tagged as :latest or with specific version numbers): These are minimal images containing only the application and its runtime dependencies. To reduce the attack surface, they do not contain a shell or a package manager.
2. Development Images (tagged with the -dev suffix): These include additional software such as shells and package managers, making them suitable for building or debugging.

Best Practice: For production environments, use multi-stage builds. Use the -dev variant to compile or build your application, then copy the resulting artifacts into a minimal production image to maintain a secure, small footprint.

To ensure smooth container lifecycle management, follow these logging and signal patterns:

• Signals: Images are designed to handle SIGTERM properly. This ensures that when you stop a container (e.g., via docker kill), the process exits immediately rather than waiting for the 10-second Docker timeout.
• Logging:
  • Normal logs must stream to stdout.
  • Error logs must stream to stderr.
  • Avoid writing logs to files inside the image, as this can consume disk space over time. Always stream logs so the container runtime can capture them.

The static image does not follow traditional software versioning because it contains minimal software. Updates are typically routine rebuilds for security patches and do not represent functional changes.

• Recommended tags: :latest or :latest-glibc are generally safe to use.
• Best practice for production: Pin the image reference by digest to ensure immutability. You can use tools like digestabot to automate updates to the image digest.

The Chainguard Apache Tomcat image is designed as a secure, drop-in replacement for the official Tomcat image. Key characteristics include:

• Non-root execution: The image does not operate as the root user.
• Minimal footprint: It includes only the minimum packages required to function, which improves security by reducing the attack surface.
• No shell/package manager: Standard production images (including :latest) typically do not contain a shell or a package manager.
• Development variants: For debugging or building, use the -dev variant which includes additional software like shells and package managers. It is recommended to use multi-stage builds to copy artifacts from a -dev variant into a minimal production image.

Chainguard provides two main types of container images to balance security and usability:

1. Production Images (tagged :latest or with specific versions): These are minimal images containing only the application and its runtime dependencies. To reduce attack surface, they do not include a shell or a package manager.
2. Development Images (tagged with -dev): These include additional software such as shells and package managers, which are useful for building or debugging.

Best Practice: Use multi-stage builds to copy necessary artifacts from a -dev variant into a minimal production image for deployment.

Chainguard provides different variants of container images to balance security and usability:

• Production Images (Default/Tagged): These are minimal images containing only the application and its runtime dependencies. They typically do not contain a shell or a package manager to reduce the attack surface.
• Development Images (-dev variant): These include shells and package managers, making them suitable for building or debugging.

Best Practice: Use multi-stage builds to install software in a -dev variant and then copy the resulting artifacts into a minimal production image.

Chainguard provides two main types of images:

1. Production Images (Default/Latest): These are minimal images containing only the application and its runtime dependencies. They do not contain a shell or a package manager, which reduces the attack surface.
2. Development Images (-dev variants): These include additional software like shells and package managers, making them useful for building or debugging.

Best Practice: Use multi-stage builds to perform your build/debug steps in a -dev image, then copy the resulting artifacts into a minimal production image.