Security

This page covers what Collectord runs as, what it touches on the host and the cluster, and what you can lock down. If you’re walking through a security review, this is the short version of the answers.

Collectord

Image

We build our standard image from scratch, a 0-size base: there’s no shell, no package manager, no interpreter to pivot from. The Collectord image ships only what’s required to run, all taken from Debian 13:

• the collectord binary;
• the system libraries it links against;
• a set of root certificates;
• a timezone database.

It also carries the glibc compatibility libraries (libpthread, librt, libanl, libutil) that runtime security agents injected into a container expect. Collectord itself doesn’t use them.

For OpenShift, we also publish a Red Hat-certified image hosted on the Red Hat registry. It’s based on a RHEL image, which we keep up to date and track for vulnerabilities in the base.

Before 26.10, the standard image’s system libraries came from Debian 12, and it had no glibc compatibility libraries.

Container configuration

To collect logs and metrics from the nodes, the Collectord DaemonSet needs access to the host filesystem, so its container runs privileged. Collectord treats the host as read-only. The only thing it writes back is acknowledgement state, in a small database under /var/lib/collectorforopenshift by default. If you configure a volume database, it goes in the volume root instead.

If you skip the volume database, you can make the host filesystem read-only. Collectord still needs write access to its primary database directory (the data folder).

The addon Deployment, which reads events and objects from the API server, runs unprivileged: it drops every capability, forbids privilege escalation, and runs under the container runtime’s default seccomp profile. It stays root only to read the database the DaemonSet writes on the node.

Collectord also reads from the API Server. We scope that access with RBAC to the read permissions it needs, nothing more. It reads Secrets with get alone, for the one Secret a SplunkOutput names, and isn’t granted nodes/proxy.

Before 26.10, the addon container ran privileged, and the ClusterRole granted get, list and watch on Secrets and access to nodes/proxy.

Using secrets to manage configurations

To store the HEC token and license key as OpenShift Secrets rather than plain ConfigMap values, see Using secrets to manage configurations.

Internet access

The default license requires internet access so license clients can verify against our license server. If your environment doesn’t allow outbound traffic, we can issue a license that doesn’t require verification: reach out and we’ll set you up.

Collectord also forwards anonymous telemetry to our license server. You can turn that off in the configuration.

Connection to Splunk HTTP Event Collector

We recommend SSL for the connection to Splunk HEC. To configure a secure SSL connection between Collectord and HEC, see Splunk output.

FIPS 140 compliance

For environments under FedRAMP, FIPS 140-3, or other federal, finance or healthcare compliance regimes, Collectord ships a FIPS-validated container image. The FIPS build is the same Collectord agent. It differs only in how it routes cryptographic operations: instead of Go’s standard crypto packages, the binary calls into the FIPS-validated module from Go’s crypto/fips140 (Go 1.24+).

Pulling the FIPS image

The FIPS image carries a -fips suffix on the tag, and like the regular image it covers both amd64 and arm64:

1docker pull registry.outcold.solutions/outcoldsolutions/collectorforopenshift:26.10.1-fips

To switch your DaemonSet and addon Deployment to FIPS, change the image: tag in the manifest from :26.10.1 to :26.10.1-fips. No other configuration changes are required. The Red Hat certified image has no FIPS variant.

FIPS-enabled vs FIPS-enforced

Collectord supports two FIPS modes, controlled by the standard Go runtime variable GODEBUG:

• FIPS-enabled (default for the FIPS image). Collectord loads the FIPS-validated module and uses it for cryptography, but the Go runtime still falls back to non-FIPS algorithms if a caller explicitly requests one. Suitable for most compliance regimes.
• FIPS-enforced. Set GODEBUG=fips140=only on the container. Any code path that would use a non-FIPS algorithm panics instead of falling back. Required for the strictest compliance interpretations.

To run the agent FIPS-enforced, add the variable to the container spec of the DaemonSet and the addon Deployment:

1env:
2  - name: GODEBUG
3    value: "fips140=only"

Verifying the mode is active

At startup, Collectord logs whether FIPS mode is enabled or enforced and which validated module version is in use. To check a running pod:

1oc logs -n collectorforopenshift <pod> | grep -i fips

You should see a line like FIPS 140 mode enabled (v1.0.0) or FIPS 140 mode enforced (v1.0.0).

The collectord verify and collectord diag commands also report the FIPS state in their output, which is useful for support bundles and audit evidence:

1oc exec -n collectorforopenshift <pod> -- /collectord verify | grep -i fips

What the FIPS image does not change

The FIPS image is about cryptographic algorithms only. It doesn’t alter Collectord’s RBAC, network behavior, or feature set. Annotations, configuration files, and dashboards work identically. Performance is within a few percent of the non-FIPS build.

If you need an air-gapped license (no outbound to our license server) for a FIPS-restricted environment, reach out: we issue them on request.