By Surya, Steve, and Swapnil

Last updated: June 2026

Primary keyword: container security image signing STIG Kubernetes
Meta description: How Kloudfuse hardened every container with UBI9-minimal base images, STIG compliance, cryptographic image signing, and non-root execution by default.
Slug: /blog/container-security-image-signing-stig-nonroot

Your security team asks a straightforward question: "Can you verify the integrity of every container image running in your observability platform?" For most Kubernetes deployments, the honest answer is "not really." Images are pulled from public registries, base images are whatever the Dockerfile specified two years ago, and nobody has checked whether the running containers match what was built.

Container security in observability platforms is particularly important because these platforms have read access to your production telemetry. An observability platform with a compromised container image can exfiltrate metrics, logs, and traces from every service in your infrastructure. The attack surface is broad by design: the platform needs access to everything it monitors.

This post covers how we hardened container security across the entire Kloudfuse platform in 4.0. We'll walk through the migration to Red Hat UBI9-minimal base images, STIG hardening at the OS level, cryptographic signing of images and Helm charts, non-root execution by default, and OIDC federation for credential-free image pulls. These aren't configuration options. They're how the containers ship.

Why Does the Base Image Matter?

Every container image starts with a base image. That base image determines the initial attack surface: which packages are installed, which libraries are linked, which system utilities are available, and which CVEs you inherit before writing a single line of application code.

Kloudfuse 4.0 migrated every container image to Red Hat UBI9-minimal. UBI (Universal Base Image) 9 is Red Hat's enterprise-grade, freely redistributable container base. The "minimal" variant strips the image to essentials: a package manager (microdnf), core libraries, and not much else. Compared to full base images, UBI9-minimal has fewer installed packages, a smaller attack surface, and faster image pull times.

The migration from previous base images was a significant effort across all platform services. Each service's dependencies were audited, unnecessary packages were removed, and the build pipeline was updated to produce consistent UBI9-minimal-based images across the entire platform.

Red Hat's CVE patching for UBI9 means the base image receives security updates on a predictable schedule. When a vulnerability is discovered in a system library, Red Hat publishes a patched image, and Kloudfuse's build pipeline picks it up in the next release cycle.

How Does STIG Hardening Work at the Container Level?

STIG (Security Technical Implementation Guide) is a set of configuration standards published by the Defense Information Systems Agency (DISA) for hardening systems against known attack vectors. For containers, STIG compliance covers file permissions, service configurations, network settings, and cryptographic policies.

In Kloudfuse 4.0, STIG hardening is applied at the container image level during the build process:

FIPS crypto policy enabled at the operating system level across all services. The FIPS 140-3 validated cryptographic modules are embedded in every container image at build time. To activate strict FIPS enforcement, set global.fips.enabled: true in your Helm values. The modules ship with every image; the Helm flag activates the enforcement policy.

File system hardening. Unnecessary SUID/SGID bits are removed. Default file permissions are tightened. Temporary directories are configured with appropriate restrictions.

Service minimization. Only the processes required by the specific Kloudfuse service run in each container. No SSH daemon, no cron, no unnecessary system services.

The critical distinction: this is how the containers ship, not a post-deployment hardening guide. For organizations operating under DoD mandates, CMMC Level 2 requirements, or agency-specific STIG policies, the platform meets the baseline without additional remediation. The alternative pattern (publishing a 40-page hardening guide that customers must follow after deployment) transfers the compliance burden to the customer and creates drift between the vendor's tested configuration and the customer's hardened configuration.

How Does Cryptographic Image Signing Work?

Image signing answers the question "is this container image exactly what the vendor built, or has it been modified?" Without signing, a compromised registry, a man-in-the-middle attack, or a misconfigured image mirror could serve a modified image that looks legitimate but contains malicious code.

Kloudfuse cryptographically signs all container images and Helm charts. Customers can verify image integrity before a single pod runs in their cluster. The verification process is documented in the image signature verification guide.

The signing approach uses the Sigstore ecosystem, which provides:

• Keyless signing. Signing identities are tied to OIDC providers (GitHub Actions, GitLab CI) rather than long-lived private keys. This eliminates the key management burden and the risk of key compromise.

• Transparency logging. Signing events are recorded in an immutable public ledger (Rekor), providing an audit trail of who signed what and when.

• Verification tooling. Standard tools (cosign) verify signatures at image pull time, deployment time, or as a policy gate in the CI/CD pipeline.

For customers with admission controllers (like Kyverno or OPA Gatekeeper), image signature verification can be enforced as a cluster policy: no unsigned images run, period. This creates a hard boundary where every running container has a verified chain of custody from the build system to the cluster.

Helm chart signing provides the same integrity guarantee for the deployment configuration. A signed chart ensures that the Kubernetes manifests, default values, and deployment templates match what Kloudfuse published.

Why Non-Root by Default?

Running containers as root is one of the most common container security anti-patterns. A root process inside a container has elevated privileges that, combined with a container escape vulnerability, can compromise the host node. The CVE database includes multiple container escape vulnerabilities that require root inside the container to exploit.

In Kloudfuse 4.0, every service runs as non-root by default. Service accounts and security contexts are configurable via Helm values, giving platform teams control over privilege boundaries:

securityContext:

  runAsNonRoot: true

  runAsUser: 1000

  fsGroup: 1000

  capabilities:

    drop:

      - ALL

This eliminates an entire class of container escape vulnerabilities for the observability platform. The tradeoff is that some operations that traditionally required root (binding to privileged ports, accessing certain device files) need alternative approaches. The platform uses non-privileged ports (Envoy Gateway uses 10080/10443 instead of 80/443) and delegates host-level operations to properly scoped init containers where absolutely necessary.

How Does OIDC Federation Eliminate Long-Lived Credentials?

Container images need to be pulled from a registry. Traditionally, this requires a registry credential (pull secret) stored as a Kubernetes Secret. That credential is long-lived, stored on disk, and represents a persistent attack vector.

Kloudfuse supports OIDC federation for image pulls from AWS ECR. Instead of a static credential, the Kubernetes service account federates with AWS IAM through OIDC. The cluster's OIDC provider is trusted by AWS, and short-lived tokens are generated automatically for each image pull.

The benefits:

• No static secrets. There is no pull secret to leak, rotate, or manage.

• Automatic expiration. Tokens are short-lived and cannot be reused after expiration.

• CI/CD integration. External partners and CI/CD systems can pull images using the same federation model, without receiving long-lived credentials from the Kloudfuse team.

This is documented in the OIDC AWS authentication guide and aligns with the broader industry move toward credential-free workload identity.

What Does the Full Supply Chain Look Like?

Each security measure addresses a different point in the supply chain:

A compromise at any single stage is contained by the protections at other stages. A tampered base image is caught by signature verification. A stolen credential is useless with OIDC federation. A container escape is limited by non-root execution. Defense in depth means no single failure compromises the entire chain.

How Does This Compare to the Typical Vendor Approach?

Most observability vendors address container security in one of three ways:

Documentation-based hardening. The vendor publishes a hardening guide. The customer is responsible for applying it. Compliance depends on the customer following every step correctly, and there's no verification that the running system matches the hardened specification.

Premium security tier. Hardened images, signed artifacts, and STIG compliance are available in a separate product tier (typically the "federal" or "enterprise" SKU). The standard product doesn't include them.

Selective hardening. Some components are hardened (usually the agent or collector), while the backend services run standard images. The security posture has gaps between hardened and unhardened components.

Kloudfuse's approach is uniform: every container, every service, every release. The same supply chain security that federal customers require ships to every customer. There is no separate hardened product. The standard product is the hardened product.

CEO Pankaj Thakkar framed this as a design principle: "Enterprise buyers should not have to choose between strong security and operational simplicity." The foundational security posture, including STIG hardening, non-root execution, and signed images, is a property of the build system. FIPS 140-3 cryptographic modules are embedded at build time, with strict enforcement activated via a single Helm flag. There is no separate hardened product. The standard product is the hardened product.

The Design Decision: Build-Time vs. Deploy-Time Hardening

The fundamental choice was whether to harden at build time (produce hardened images) or at deploy time (provide tooling for customers to harden standard images).

Deploy-time hardening is more flexible. Customers can choose their own hardening profile, adjust for their specific compliance requirements, and use their own tools. But it creates a gap between the vendor's tested configuration and the customer's deployed configuration. Issues that appear only in the hardened configuration are nobody's fault and everybody's problem.

Build-time hardening means Kloudfuse tests, certifies, and supports the hardened configuration. There's one configuration matrix, not a combinatorial explosion of customer hardening choices. When a customer reports an issue, we're running the same images they are.

The tradeoff is reduced flexibility. Customers who need a specific hardening profile beyond what Kloudfuse ships need to request it or apply additional layers. We accepted this because the vast majority of security requirements (STIG, FIPS, non-root, signed images) are common across regulated industries. Standardizing on a single, thoroughly tested hardening profile serves most customers better than a configurable toolkit that each customer assembles differently.

Next Steps

The security documentation covers the platform's security architecture. The image signature verification guide walks through verifying container image integrity. The OIDC AWS authentication guide covers credential-free image pulls.

What does your container security posture look like for observability tooling? Are you verifying image signatures, or is the observability platform a gap in your supply chain security? We'd be interested to hear how teams are approaching this.