sentry-fips

packaged by Chainguard

Chainguard Container for sentry-fips

Sentry is a developer-first error tracking and performance monitoring platform. This FIPS-enabled image runs the Sentry web service, task workers, schedulers, and consumers for self-hosted Sentry.

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/sentry-fips:latest

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

Compatibility Notes

Chainguard's sentry-fips image is a FIPS-enabled variant of the sentry image and is comparable to the upstream ghcr.io/getsentry/sentry image used by self-hosted Sentry. It keeps the upstream runtime layout: the sentry user (UID 999), the /usr/src/sentry working directory, the self-hosted configuration in /etc/sentry (SENTRY_CONF), the /data volume, and the python3 /docker_entrypoint.py run web entrypoint.

In addition to the differences described for the sentry image (the virtual environment at /usr/share/sentry/venv on PATH, no odiff binary, and no shell), this variant differs from upstream in the following ways:

• Python packages that bundle their own crypto libraries in their wheels (cryptography, grpcio, psycopg2, lxml, xmlsec, and confluent-kafka) are replaced with builds that use the system OpenSSL.
• The web service runs on gunicorn instead of granian, because granian links a non-FIPS TLS stack. Only the WSGI interface is supported, and granian's worker lifetime and memory limit settings do not apply.
• The hf-xet package and the emmett55 web framework, both of which bundle non-FIPS crypto, are not installed. Hugging Face downloads fall back to plain HTTP transfers, and the apigw proxy, which self-hosted Sentry does not run, is unavailable.
• The image has no shell. Images that extend it with RUN steps, such as the self-hosted sentry/Dockerfile, must build from the -dev variant.
• The community sentry-kubernetes chart runs rm in the taskworker liveness probe and sh in the nodestore init container. Use the -dev variant for those containers, or override sentry.taskWorker.livenessProbe.
• Content hashes that Sentry computes with MD5 and SHA-1 for fingerprints, cache keys, and ETags are marked as non-security uses. The legacy organization invite token uses SHA-256 instead of MD5, so invite links that carry an MD5 legacy token stop working after an existing installation moves to this image. New installations are not affected.

FIPS Support

The sentry-fips Chainguard Container ships with a validated redistribution of OpenSSL's FIPS provider module, and Sentry's hashing and TLS run through it. For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

Relay authentication signing in the bundled sentry-relay Python module uses an Ed25519 implementation that does not run through the OpenSSL FIPS provider. Sentry uses it to verify requests from Relay instances.

Prerequisites

Sentry needs a PostgreSQL database and a Redis server. The examples below use the postgres and redis Chainguard Containers; FIPS deployments can use their postgres-fips and redis-fips counterparts.

Getting Started

Create a network and start PostgreSQL and Redis:

docker network create sentry
docker run -d --name sentry-postgres --network sentry \
  -e POSTGRES_USER=sentry -e POSTGRES_PASSWORD=sentry -e POSTGRES_DB=sentry \
  cgr.dev/chainguard/postgres:latest
docker run -d --name sentry-redis --network sentry cgr.dev/chainguard/redis:latest

Create an environment file that points Sentry at the two services:

cat > sentry.env <<EOF
SENTRY_POSTGRES_HOST=sentry-postgres
SENTRY_DB_NAME=sentry
SENTRY_DB_USER=sentry
SENTRY_DB_PASSWORD=sentry
SENTRY_REDIS_HOST=sentry-redis
SENTRY_SECRET_KEY=$(openssl rand -hex 32)
EOF

Run the database migrations and create an administrator account:

docker run --rm --network sentry --env-file sentry.env cgr.dev/ORGANIZATION/sentry-fips:latest upgrade --noinput
docker run --rm --network sentry --env-file sentry.env cgr.dev/ORGANIZATION/sentry-fips:latest \
  createuser --email admin@example.com --password 'change-me-please' --superuser --no-input

Start the web service and confirm it is healthy:

docker run -d --name sentry-web --network sentry -p 9000:9000 --env-file sentry.env cgr.dev/ORGANIZATION/sentry-fips:latest
curl http://localhost:9000/_health/

ok

You can now sign in at http://localhost:9000 with the account you created. The same image runs the background services when you change the command, for example the task scheduler:

docker run -d --name sentry-scheduler --network sentry --env-file sentry.env \
  cgr.dev/ORGANIZATION/sentry-fips:latest run taskworker-scheduler

To use this image with self-hosted Sentry, set SENTRY_IMAGE=cgr.dev/ORGANIZATION/sentry-fips:latest-dev in its .env file before running ./install.sh. Self-hosted builds its own image on top of SENTRY_IMAGE with RUN steps, which need the shell in the -dev variant. The image includes update-ca-certificates, which the self-hosted entrypoint runs to load certificates from its certificates directory. The sentry-cleanup service installs cron with apt-get and does not build on this image.

Configuration

The image ships the self-hosted sentry.conf.py and config.yml in /etc/sentry. The SENTRY_* environment variables shown above cover the database and Redis; SENTRY_MEMCACHED_HOST and SENTRY_EMAIL_HOST configure Memcached and outgoing email the same way. For anything beyond that, mount your own configuration directory over /etc/sentry:

docker run -d --name sentry-web --network sentry -p 9000:9000 --env-file sentry.env \
  -v "$PWD/sentry-config:/etc/sentry:ro" \
  cgr.dev/ORGANIZATION/sentry-fips:latest

Uploaded files, debug symbol caches, and release file caches are written to /data, which is owned by the sentry user. Mount a persistent volume there in production.

On Kubernetes, set enableServiceLinks: false in the pod spec when your PostgreSQL, Redis, Memcached, or SMTP Services are named sentry-postgres, sentry-redis, sentry-memcached, or sentry-email. Otherwise Kubernetes injects variables such as SENTRY_REDIS_PORT=tcp://... that override the ports sentry.conf.py reads.

Documentation and Resources

• Self-Hosted Sentry documentation
• Self-hosted Sentry repository
• Sentry source repository
• FIPS-enabled Chainguard Containers on Chainguard Academy

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.