influxdb-fips

packaged by Chainguard

Chainguard Container for influxdb-fips

FIPS-enabled minimal image with InfluxDB.

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/influxdb-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

The Chainguard FIPS Image for InfluxDB is a FIPS-enabled build of InfluxDB 2.7 — a scalable datastore for metrics, events, and real-time analytics — for environments that require FIPS 140 validated cryptography. It runs against Chainguard's FIPS-validated system OpenSSL and, like most other Chainguard Images, has few-to-zero CVEs and does not run as the root user: it runs as the nonroot influxdb user (uid/gid 1000) and serves the HTTP API and UI on port 8086. Apart from the password-hashing change described under FIPS Support, it is a drop-in replacement for the standard influxdb image.

FIPS Support

InfluxDB normally hashes user passwords with bcrypt (golang.org/x/crypto/bcrypt) — which is not FIPS-approved (bcrypt vendors its own Blowfish implementation and does not route through OpenSSL). For FIPS compliance this build replaces the password-hashing paths (tenant, v1/authorization, v1/services/meta) with a drop-in shim that uses PBKDF2-HMAC-SHA256 (golang.org/x/crypto/pbkdf2, whose HMAC-SHA256 routes through the FIPS-validated OpenSSL under the go-fips toolchain). Only password hashing changes — data writes, queries, Flux, buckets, and API tokens behave exactly as in the standard image.

What this means in practice:

• Stored password hashes change format from bcrypt ($2a$…) to $pbkdf2-sha256$<iterations>$<salt>$<key> (600,000 iterations, per OWASP guidance). A fresh deployment stores the new format automatically.
• Token-based API access is unaffected — tokens are not password hashes. Automation that authenticates with a token needs no changes.
• Migrating from the standard (non-FIPS) image: existing bcrypt-hashed users cannot sign in on the FIPS build — it cannot read a bcrypt hash to verify or re-hash it, and there is no automatic in-place migration. Reset each affected user's password once on the FIPS build (for example influx user password --name <user>, or the InfluxDB UI, or the /api/v2 password endpoint) so it is re-stored as PBKDF2. Buckets, tokens, dashboards, and time-series data are unchanged.

Getting Started

The image serves InfluxDB's HTTP API and UI on port 8086, persists data under /var/lib/influxdb2, and reads configuration from /etc/influxdb2 (falling back to /etc/defaults/influxdb2/config.yml). It runs as the nonroot influxdb user (uid/gid 1000); mount volumes that user can read/write.

Run InfluxDB with initial setup

On first start, the entrypoint can create the initial user, organization, bucket, and admin token when DOCKER_INFLUXDB_INIT_MODE=setup is set. The admin password is hashed with PBKDF2 (the FIPS path):

docker run -d --name influxdb -p 8086:8086 \
  -v "$PWD/influxdb-data:/var/lib/influxdb2" \
  -e DOCKER_INFLUXDB_INIT_MODE=setup \
  -e DOCKER_INFLUXDB_INIT_USERNAME=admin \
  -e DOCKER_INFLUXDB_INIT_PASSWORD='change-me-please' \
  -e DOCKER_INFLUXDB_INIT_ORG=acme \
  -e DOCKER_INFLUXDB_INIT_BUCKET=metrics \
  -e DOCKER_INFLUXDB_INIT_ADMIN_TOKEN='my-super-secret-admin-token' \
  cgr.dev/ORGANIZATION/influxdb-fips:latest

The UI and API are then available at http://localhost:8086. Sign in with the username/password above, or authenticate the API with the admin token. (DOCKER_INFLUXDB_INIT_ADMIN_TOKEN is optional; if omitted, a random token is generated and printed in the container logs.) Use DOCKER_INFLUXDB_INIT_MODE=upgrade instead to migrate an existing InfluxDB 1.x data directory.

Write and query data

Using the bundled influx CLI against the running server (token from setup):

export INFLUX_HOST=http://localhost:8086
export INFLUX_TOKEN='my-super-secret-admin-token'

influx write --org acme --bucket metrics --precision s \
  'home,room=living temp=22.4,hum=36.0 1641024000'

influx query --org acme 'from(bucket:"metrics") |> range(start:-1h)'

Or directly over the HTTP API:

curl -s -XPOST "http://localhost:8086/api/v2/write?org=acme&bucket=metrics&precision=s" \
  -H "Authorization: Token my-super-secret-admin-token" \
  --data-binary 'home,room=living temp=22.4 1641024000'

Deploy on Kubernetes (Helm)

InfluxData's influxdb2 chart works with this image; override the image and set the admin credentials (the password is stored as a PBKDF2 hash):

helm repo add influxdata https://helm.influxdata.com/
helm install influxdb influxdata/influxdb2 \
  --set image.repository=cgr.dev/ORGANIZATION/influxdb-fips \
  --set image.tag=latest \
  --set adminUser.organization=acme \
  --set adminUser.bucket=metrics \
  --set adminUser.user=admin \
  --set adminUser.password='change-me-please' \
  --set adminUser.token='my-super-secret-admin-token'

The pod runs as the nonroot influxdb user and serves on port 8086.

Documentation and Resources

• InfluxDB GitHub repository
• InfluxDB 2 documentation
• Standard (non-FIPS) Chainguard InfluxDB image
• InfluxData Helm charts

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.