Chainguard Image for python-fips

Chainguard Images are regularly-updated, minimal container images with low-to-zero CVEs.

Download this Image

This image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/python-fips: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-fips Chainguard Image provides a FIPS-enabled Python runtime suitable for workloads such as web applications, CLI utilities, interfacing with APIs, or other tasks.

Compatibility Notes

Where possible, the python-fips Chainguard Image is built for compatibility with the Docker official image for Python.

The python-fips Chainguard Image ships with a validated redistribution of the OpenSSL's FIPS provider module. For more on FIPS support in Chainguard Images, consult the guide on FIPS-enabled Chainguard Images on Chainguard Academy

By default, the python-fips Chainguard Image runs as a non-root user. You may need to use USER root to perform tasks requiring elevated privileges.

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.

Variants

We have two image variants available:

• A python-fips:latest-dev variant that contains the pip and apk package managers and the bash, ash, and sh shells.
• A minimal runtime variant that does not contain shells and package managers for additional security.

To pull the minimal runtime variant from cgr.dev:

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

To pull the dev variant:

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

Getting Started

Example: Test for Unapproved FIPS Algorithm

The MD5 algorithm is commonly used to verify data integrity. According to the FIPS framework, MD5 is not suitable for applications like SSL certificates or digital signatures that rely on collision resistance for digital security. Since MD5 is not approved under the FIPS framework, we can test for FIPS compliance by attempting to use this algorithm. This should resultin an error.

First, create a project folder for our test:

mkdir -p ~/fips-test && cd $_

Next, create a Python script that attempts to use the MD5 algorithm:

cat << 'EOF' > fips-test.py
import hashlib

hashlib.md5("test_str".encode('utf-8')).hexdigest()
EOF

Create a Dockerfile for our image build:

ORGANIZATION=my-organization

cat << EOF > Dockerfile
FROM cgr.dev/$ORGANIZATION/python-fips:3.10

WORKDIR /app

COPY fips-test.py .

USER root

CMD ["fips-test.py"]
EOF

Build the image:

docker build . -t fips-test

Finally, run the test:

docker run fips-test

This should produce output similar to the following:

Traceback (most recent call last):
  File "/app/./fips-test.py", line 3, in <module>
    print(hashlib.md5("test_str".encode('utf-8')).hexdigest())
ValueError: [digital envelope routines] unsupported

Since MD5 isn't supported in our FIPS-enabled container, we receive an error when attempting to use this algorithm. If you see the above error, the test was successful.

Example: Minimal CLI Application

The following provides an example of a CLI application that does not require additional Python dependencies.

First, create a project folder for the example and change the workingdirectory to that folder:

mkdir -p ~/python-cli && cd $_

Next, create the Python script:

cat << 'EOF' > app.py
from sys import argv

if len(argv) < 2:
    print("Hello, Linky! 🐙")
else:
    print(f"Hello, {argv[1]}!")
EOF

Create a Dockerfile for our image build. (Make sure to replace the value of the ORGANIZATION environmental variable with the name of your organization.)

ORGANIZATION=my-organization

cat << EOF > Dockerfile
FROM cgr.dev/$ORGANIZATION/python-fips:latest

WORKDIR /cli-app

COPY app.py .

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

Build the image:

docker build . -t python-cli

Run the container with the following:

docker run python-cli

You should see the following output:

Hello, Linky! 🐙

You can also run the CLI application with an argument:

docker run python-cli "FIPS-Compliant Chainguard User"

Example: Web Application with Multi-Stage Build

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 example uses a multi-stage build to install packages necessary to run a Flask web application.

First, create a project folder for the example:

mkdir -p ~/python-web-app && cd $_

Next, create the script for our Flask web application:

cat << 'EOF' > app.py
from flask import Flask

app = Flask(__name__)

@app.route('/')
def index():
    """Example index page."""
    octopuses = '🐙' * 10
    return f'<h1>Linky Is Best</h1><p>{octopuses}</p>'


if __name__ == "__main__":
    app.run(debug=True)
EOF

Next, create a requirements.txt file listing dependencies:

cat << 'EOF' > requirements.txt
Flask
gunicorn
EOF

Finally, let's create a Dockerfile for our image build. (Make sure to replace the value of the ORGANIZATION environmental variable with the name of your organization.)

ORGANIZATION=my-organization

cat << EOF > Dockerfile
FROM cgr.dev/$ORGANIZATION/python-fips:latest-dev AS dev

WORKDIR /flask-app

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

FROM cgr.dev/$ORGANIZATION/python-fips:latest

WORKDIR /flask-app

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

EXPOSE 8000

ENTRYPOINT ["python", "-m", "gunicorn", "-b", "0.0.0.0:8000", "app:app"]
EOF

Build the image:

docker build . -t python-web-app

Run a container to serve the web application:

docker run -p 8000:8000 python-web-app

The application should now be accessible at http://localhost:8000/.

Documentation and Resources

• Chainguard Academy: FIPS-enabled Chainguard Images
• 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

Contact Support

If you have a Zendesk account (typically set up for you by your Customer Success Manager) you can reach out to Chainguard's Customer Success team through our Zendesk portal.

What are Chainguard Images?

Chainguard Images are a collection of container images designed for security and minimalism.

Many Chainguard Images are distroless; they contain only an open-source application and its runtime dependencies. These images do not even contain a shell or package manager. Chainguard Images are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a secure software supply chain.

The main features of Chainguard Images include:

• Minimal design, with no unnecessary software bloat
• Automated nightly builds to ensure Images are completely up-to-date and contain all available security patches
• High quality build-time SBOMs (software bills of materials) attesting the provenance of all artifacts within the Image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

-dev Variants

As mentioned previously, Chainguard’s distroless Images have no shell or package manager by default. This is great for security, but sometimes you need these things, especially in builder images. For those cases, most (but not all) Chainguard Images come paired with a -dev variant which does include a shell and package manager.

Although the -dev image variants have similar security features as their distroless versions, such as complete SBOMs and signatures, they feature additional software that is typically not necessary in production environments. The general recommendation is to use the -dev variants only to build the application and then copy all application artifacts into a distroless image, which will result in a final container image that has a minimal attack surface and won’t allow package installations or logins.

That being said, it’s worth noting that -dev variants of Chainguard Images are completely fine to run in production environments. After all, the -dev variants are still more secure than many popular container images based on fully-featured operating systems such as Debian and Ubuntu since they carry less software, follow a more frequent patch cadence, and offer attestations for what they include.

Learn More

To better understand how to work with Chainguard Images, we encourage you to visit Chainguard Academy, our documentation and education platform.