python

packaged by Chainguard

Chainguard Container for python

Minimal Python image based on Wolfi.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/python:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Description

The python Chainguard Image provides a minimal Python runtime suitable for workloads such as web applications, CLI utilities, interfacing with APIs, or other tasks.

Variants

We have three image variants available:

• A python:latest-dev variant that contains the pip, uv, and apk package managers and the bash, ash, and sh shells.
• A minimal runtime variant that removes shells and package managers for additional security.
• A -full variant, which acts as an upstream-compatible drop-in replacement for the corresponding upstream image.
  • Full variants exist primarily to ease migration before moving to a standard or development variant. We recommend treating full variants as a starting point rather than a destination.

To pull the minimal runtime variant from cgr.dev:

docker pull cgr.dev/chainguard/python:latest

To pull the dev variant:

docker pull cgr.dev/chainguard/python:latest-dev

Usage Notes

The entrypoint for the python Chainguard Image is /usr/bin/python. Commands run as part of docker run or a CMD statement in a Dockerfile will be passed as arguments to python.

To access the shell in the python:latest-dev image, you'll need to include an --entrypoint option, as in the following example.

docker run -it --entrypoint /bin/bash chainguard/python:latest-dev

Also note that the python image uses the nonroot user by default. To perform operations such as installing packages with apk, run the image as root.

docker run -it --user root --entrypoint /bin/bash chainguard/python:latest-dev

We recommend against using the root user in a production environment.

Packages

If you require additional packages that can be installed with the pip package manager, we recommend using a multistage build. This process involves installing packages in a virtual environment using the latest-dev variant, then copying this environment over to the minimal runtime image.

The following is a minimal example of a Dockerfile that uses a multistage build to run an app.py script after installing dependencies listed in a requirements.txt file.

# syntax=docker/dockerfile:1

FROM cgr.dev/chainguard/python:latest-dev as dev

WORKDIR /app

RUN python -m venv venv
ENV PATH="/app/venv/bin":$PATH
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt

FROM cgr.dev/chainguard/python:latest

WORKDIR /app

COPY app.py app.py
COPY --from=dev /app/venv /app/venv
ENV PATH="/app/venv/bin:$PATH"

ENTRYPOINT ["python", "app.py"]

For a more complete example, see Getting Started with the Python Chainguard Image on Chainguard Academy.

Chainguard Python Hardened

Chainguard's Python builds deviate from upstream Python in their TLS and hashlib defaults.

TLS

Chainguard OS doesn't support the deprecated TLS 1.1 and earlier protocol versions. However, a lot of Python software still uses the ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_TLSv1_1, and ssl.PROTOCOL_TLSv1_2 constants, which at one time were the way to opt in to a secure protocol version. Stock Python compiled against Chainguard Hardened OpenSSL doesn't provide these constants, so code that references them fails with an AttributeError.

To preserve source compatibility, Chainguard patches Python to always provide the legacy constants. They're aliases of ssl.PROTOCOL_TLS, so rather than pinning an old protocol version, connections negotiate TLS 1.3, or TLS 1.2 with peers that don't support TLS 1.3:

>>> import ssl
>>> ssl.PROTOCOL_TLSv1_1 is ssl.PROTOCOL_TLS
True
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1_1)
>>> ctx.minimum_version, ctx.maximum_version
(<TLSVersion.TLSv1_2: 771>, <TLSVersion.TLSv1_3: 772>)

For the full list of protocol versions and ciphers available by default and as opt-ins, see OpenSSL 4.0 in Chainguard OS.

hashlib

The Python hashlib module offers many digests. Some of them, such as MD5 and SHA-1, are considered weak, but all of them are available by default. Each digest constructor accepts an optional usedforsecurity keyword argument, which defaults to True.

Chainguard provides a set of python-hardened packages that block weak digests at different levels when they're used for security purposes. Add one of these packages to the image with Custom Assembly to enforce the hash digest policy appropriate for your organization. The packages conflict with each other, so install only one.

✅ allowed, 🚫 blocked unless called with usedforsecurity=False.

Blocked digests are also refused by hashlib.new(), including OpenSSL aliases such as SHA-1 and SHA2-256. HMAC (hmac.new(), hmac.HMAC, and hmac.digest()) and hashlib.pbkdf2_hmac() take no usedforsecurity argument, because any use of them is for security, so they always refuse blocked digests.

When planning for post-quantum cryptography (PQC) safety, note that quantum algorithms in theory significantly reduce the effort of attacks on hash functions. Grover's algorithm reduces the effort of a preimage attack on an n-bit digest from 2ⁿ to 2^n/2 operations, and the Brassard, Høyer, and Tapp (BHT) algorithm reduces the effort of a collision attack from 2^n/2 to 2^n/3 operations. Carefully evaluate the security considerations of existing digest usage in your applications.

A blocked digest raises a ValueError:

>>> import hashlib
>>> hashlib.md5(b"").hexdigest()
Traceback (most recent call last):
  ...
ValueError: Chainguard python-hardened: md5 blocked. Use `usedforsecurity=False` to access
>>> hashlib.md5(b"", usedforsecurity=False).hexdigest()
'd41d8cd98f00b204e9800998ecf8427e'

A significant portion of the Python ecosystem uses these digests for non-security purposes without declaring usedforsecurity=False. For this reason, no hardened hashlib configuration can support all Python applications. For example:

• Cloud storage SDKs often use MD5 and SHA-1 to verify the integrity of multipart uploads.
• pip uses SHA-224 to name the files in its cache.

Test your application with the chosen python-hardened package before deploying it to production.

OpenSSL Versions

Tags with an -ossl35 suffix include a hardened build of OpenSSL 3.5. These tags provide the OpenSSL 3 libraries (libssl.so.3 and libcrypto.so.3) for applications that have not moved to OpenSSL 4. To pull one, run the following command:

docker pull cgr.dev/ORGANIZATION/python:latest-ossl35

Resources

• Getting Started with the Python Chainguard Image
• Migrating to Python Chainguard Images
• Updating a Python Microservice for Chainguard Images
• Debugging Distroless Images
• Blog Post: Securely Containerize a Python Application with Chainguard Images
• Video: How to containerize a Python application with a multi-stage build using Chainguard Images
• Learning Lab: Deploying a Flask App with Python and nginx Chainguard Images

Get this image as a Chainguard VM

This image is also available as a Chainguard VM, available to deploy on Amazon AWS EC2, Google Cloud Compute Engine, Microsoft Azure and On-Prem through VMware, KVM and QEMU virtualization. Complete our registration form to get access to Chainguard VMs and try it out for yourself.

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.