symbolicator-fips

packaged by Chainguard

Chainguard Container for symbolicator-fips

FIPS-enabled Symbolicator, Sentry's native symbolication service, which resolves function names, file paths, and line numbers in native stack traces, with TLS routed through the system OpenSSL FIPS provider.

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/symbolicator-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 symbolicator-fips image is comparable to the upstream Symbolicator image and is designed to be a drop-in replacement for it. It keeps the same entrypoint (/bin/symbolicator), working directory (/home/nonroot), non-root user (UID 65532), port (3021), and writable /data and /etc/symbolicator directories. Like the upstream image, it has no shell.

Symbolicator is built from source with TLS through the system OpenSSL library, which is linked dynamically, so OpenSSL security fixes reach the image through regular updates.

FIPS Support

The symbolicator-fips Chainguard Container routes TLS through the system OpenSSL FIPS provider, which openssl-config-fipshardened configures. It installs rustls-openssl as the process-wide TLS provider in place of ring, and signs Google Cloud Storage service account tokens with OpenSSL. HTTP symbol downloads use the system OpenSSL directly.

Some optional source types still reach cryptography outside the OpenSSL FIPS module:

• S3 symbol sources sign requests with pure-Rust HMAC and SHA-2, and the AWS credential client builds its own TLS configuration on aws-lc-rs.
• A GCS shared cache configured with a custom service account key signs its token with ring. Credentials from the GCS metadata server do not sign anything.
• AWS SSO credentials use ring.

Filesystem and HTTP symbol sources, which Sentry self-hosted uses by default, do not reach these paths.

For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

Getting Started

Symbolicator reads a YAML configuration file and serves its HTTP API on port 3021. Create a minimal configuration that keeps the download cache in the /data volume:

cat > config.yml <<EOF
bind: 0.0.0.0:3021
cache_dir: /data
EOF

To have something to symbolicate, create a Breakpad symbol file in the native source layout (<debug_file>/<breakpad_id>/<debug_file>.sym):

mkdir -p symbols/libexample.so/E45DB8DFAF2D09FD640C8FE377D572DE0
cat > symbols/libexample.so/E45DB8DFAF2D09FD640C8FE377D572DE0/libexample.so.sym <<EOF
MODULE Linux x86_64 E45DB8DFAF2D09FD640C8FE377D572DE0 libexample.so
FILE 0 /src/example.c
FUNC 1000 40 0 example_function
1000 40 42 0
EOF

Start the server with the configuration and the symbols directory mounted:

docker run -d --name symbolicator -p 3021:3021 \
  -v "$PWD/config.yml:/etc/symbolicator/config.yml:ro" \
  -v "$PWD/symbols:/symbols:ro" \
  cgr.dev/ORGANIZATION/symbolicator-fips:latest --config /etc/symbolicator/config.yml run

Check that the server is healthy:

curl -s --retry 10 --retry-all-errors http://localhost:3021/healthcheck

ok

Then ask it to resolve a native frame against the local symbol source:

curl -s -X POST -H 'Content-Type: application/json' http://localhost:3021/symbolicate --data '{
  "platform": "native",
  "sources": [{"id": "local", "type": "filesystem", "path": "/symbols", "layout": {"type": "native"}}],
  "modules": [{"type": "elf", "debug_id": "e45db8df-af2d-09fd-640c-8fe377d572de", "debug_file": "libexample.so", "code_file": "/usr/lib/libexample.so", "image_addr": "0x10000", "image_size": 65536}],
  "stacktraces": [{"registers": {}, "frames": [{"instruction_addr": "0x11010"}]}]
}' | jq '.stacktraces[0].frames[0] | {function, abs_path, lineno}'

{
  "function": "example_function",
  "abs_path": "/src/example.c",
  "lineno": 42
}

In a self-hosted Sentry installation, set symbolicator.options.url in Sentry's config.yml to this container's address (for example http://symbolicator:3021) and mount your configuration at /etc/symbolicator/config.yml, as the Sentry self-hosted compose file does.

Configuration

The configuration file controls the listen address, the cache, and which symbol servers Symbolicator may contact. Symbol sources (filesystem, HTTP, S3, and GCS) are normally sent by Sentry with each request, so the file mostly tunes the server itself. The cache directory must be writable by UID 65532; the image's /data directory already is, so use it or a volume mounted there. When symbol servers resolve to private addresses, such as other containers or services in the same cluster, set connect_to_reserved_ips: true, because Symbolicator refuses reserved address ranges by default.

Refer to the Symbolicator configuration documentation for every option.

Documentation and Resources

• Symbolicator documentation
• Symbolicator on GitHub
• Sentry self-hosted

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.