k6 ↔ InfluxDB TLS verification: configuring trusted internal CA for production tests

Question

The goal is to execute a k6 test that writes metrics to an InfluxDB endpoint over HTTPS in a production environment while keeping TLS certificate verification enabled, rather than disabling it with --insecure-skip-tls-verify.

By default, k6 relies on the Node.js TLS implementation and the system's root CA bundle to validate the InfluxDB server's certificate. In production, InfluxDB is often served behind an internal or corporate PKI, so the presenting certificate may be signed by a CA that is not present in the default trust store. Supplying the additional CA can be done via the NODE_EXTRA_CA_CERTS environment variable or by mounting a custom CA bundle into the k6 container, but the recommended approach for containerized CI pipelines, the behavior across different k6‑bundled Node.js versions, and whether multiple CA files can be combined remain unclear.

What is the recommended way to inject a custom CA bundle into a k6 Docker image without rebuilding the image for each certificate change?
How does NODE_EXTRA_CA_CERTS behave across different versions of the Node.js runtime bundled with k6, and are there any version‑specific caveats?
Can k6 be configured to accept multiple CA files (e.g., via a directory or a concatenated PEM) to trust both the internal PKI and public roots simultaneously?

Tasadduq Burney · Answer

Recommended Approach for Custom CA Injection
To inject a custom CA bundle into a k6 Docker container without rebuilding the image, the recommended method is to mount the CA certificate as a volume and reference it using the --tls-ca-file flag or the K6_TLS_CA_FILE environment variable.

Because k6 is written in Go, it does not rely on the Node.js runtime for its core network operations or TLS handshake. Therefore, NODE_EXTRA_CA_CERTS is ineffective for k6's internal HTTP client and metrics output. Instead, k6 uses the Go standard library's TLS implementation, which looks for certificates provided via its own configuration flags.

Implementation Steps

Prepare the Bundle: Ensure your internal CA and any necessary intermediate certificates are concatenated into a single .pem file.
Mount the Volume: Map the local certificate file into the container at runtime.
Configure k6: Pass the path to the mounted file to the k6 process.

# Example Docker run command
docker run --rm -v /path/to/internal-ca.pem:/etc/ssl/certs/internal-ca.pem 
  -e K6_TLS_CA_FILE=/etc/ssl/certs/internal-ca.pem 
  grafana/k6 run /scripts/test.js

Handling Multiple CAs and Public Roots
k6 can trust both internal PKI and public root CAs simultaneously. When you provide a file via --tls-ca-file, k6 appends these certificates to the system's default root CA pool. To trust multiple internal CAs, you must provide a concatenated PEM file containing all required certificates in sequence. k6 does not support scanning a directory for multiple .crt or .pem files.

Verification and Diagnostics
To verify the configuration is working without relying on k6 logs, you can use openssl from a similar environment to confirm the chain is valid:

openssl s_client -connect influxdb-host:8086 -CAfile /path/to/internal-ca.pem

If the handshake returns Verify return code: 0 (ok), the certificate bundle is correct. If k6 still fails, verify that the InfluxDB server is presenting the full certificate chain (including intermediates) during the TLS handshake.

Missing Diagnostic Detail
To provide a more specific recommendation regarding the system trust store, please specify the base OS image (e.g., Alpine vs. Debian) used for your k6 deployment, as this affects how the default root CA bundle is located by the Go runtime.

k6 ↔ InfluxDB TLS verification: configuring trusted internal CA for production tests

1 answer

0 question comments

Recommended Approach for Custom CA Injection

Implementation Steps

Handling Multiple CAs and Public Roots

Verification and Diagnostics

Missing Diagnostic Detail

Your perspective belongs here.