Question
k6 ↔ InfluxDB TLS verification: configuring trusted internal CA for production tests
Ash Maple
0 reputation · 02 Sept 2020, 13:06 UTC
71.8K views1
Loading…
0 reputation · 02 Sept 2020, 13:06 UTC
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?
35275 reputation · 02 Sept 2020, 17:40 UTC
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.
k6
influxdb.pem file.# 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.jsk6 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.
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.pemIf 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.
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.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 02 Sept 2020, 21:16 UTC
k6’s HTTP client and built-in output sinks, including the InfluxDB writer, are implemented in Go. TLS verification therefore uses Go’s crypto/x509 SystemCertPool, not Node.js TLS.
That means NODE_EXTRA_CA_CERTS has no effect on k6 metric output or Go HTTP requests. It would only matter for external Node.js processes you run alongside k6, not for the k6 binary itself.
For runtime CA injection without rebuilding the image, the practical path is to mount a concatenated PEM containing the internal root and any intermediates into the container’s system trust location that Go consults, e.g. /etc/ssl/certs, and ensure the file is readable at start-up. Go can trust both internal PKI and public roots from a single concatenated PEM; separate files are not aggregated automatically.
Verification can be done outside k6 with openssl s_client -connect influxdb:8086 -CAfile /path/to/bundle.pem from a matching base image before running the test.