Software supply chain security¶

Palo Alto Networks cryptographically signs every enterprise Kubernetes image and provides FIPS-compliant builds for environments that require validated cryptography. This topic describes how to verify an image's signature and how FIPS compliance works across these components.

Container image signing¶

All enterprise Kubernetes images are signed with the Palo Alto Networks public key, so you can be sure that Palo Alto Networks built and provided them, even when they're mirrored to your own registry.

To verify an image's signature with cosign verify:

1. Save the following public key to a file named venafi-enterprise-pubkey.pem. Palo Alto Networks generated it on October 15, 2023.

   -----BEGIN PUBLIC KEY-----
   MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt11/1JV1stcGQ9kXKUKb
   aHfl+0LwQHCngON+WF5WFK4+Ck5wpWR70lFHB4tFNZLFWDw4MfvqlE4c8u+/cg3Y
   twEbKDMubKC4mVG9mxxwyH20ISnJIq76sLqoFNm6IX+CIqKJWvLYtmIHqZytxEfH
   AbxyL8h5eQvxRHeZGikX5gB9yWxy/jFwi7tEKgUWOwtraD0iKvBlcaNacSVZCjsi
   P5bbklSezdjjPdFhOThhcXk1wOiKUsyiWg7hLHYmn0s6aBpCzh83OWHpwOGG4mqL
   XV+WD9NV7mC53ftsP+t11jXYLCnZYZ+jGxTAI9goF7fcRhljIcpR0diDRlt0DQV0
   6RPgYcIbsJCSNm0FbJXfQXMDhSM+fYQcqQ4c/lRjBfQX/Ic9yGrleh6KA4UQOe9i
   eMWvf0/f9j1ZCPm/5L0NKTrFffQ4Rx605CHF3IpczqZ+Ev3vIRKLyAkSRHGr3OMW
   vvsXOKJm4JmykIzpUeWgSf3Ah4Y3aJDAKwbRKmH82gvbQj+o/fHeAVyW2Ae7v5sX
   PKBkL1nj/DEmV0EOpaQEOkTkS002mB6k+5ED4Wdj2O50fa8H3MSPJUHUtB0BKnSZ
   eq0hhTNCoxzWk0tolUo6PiY2BTjm4zJ3WP+oD3/lSxMukZSUNBtLARhCqT0+MQ8c
   Ba3l7EtehQS0mpSj7xiCdP0CAwEAAQ==
   -----END PUBLIC KEY-----
   

2. Run cosign verify, substituting <latest-version> with the version you want to verify. For example, to verify the cert-manager controller:

   cosign verify private-registry.venafi.cloud/cert-manager/cert-manager-controller:<latest-version> \
     --key ./venafi-enterprise-pubkey.pem \
     --insecure-ignore-tlog
   

   About transparency logs

   Images in the private registry and your own mirror aren't recorded in a transparency log, so include the --insecure-ignore-tlog flag. Images pulled from the public registry.venafi.cloud are recorded; omit the flag to verify against the log.

   If successful, the command exits with code 0 and prints output confirming the signature, for example:

   Verification for registry.venafi.cloud/venafi-agent/venafi-agent --
   The following checks were performed on each of these signatures:
     - The cosign claims were validated
     - The signatures were verified against the specified public key
   

FIPS compliance¶

Palo Alto Networks Kubernetes components are standard Go binaries that rely on the Go standard library for cryptography. Since the Go standard library is not FIPS-validated, we also offer FIPS-compliant versions of these components.

Palo Alto Networks builds current FIPS components with upstream Go's native FIPS 140-3 support, which embeds the Go Cryptographic Module directly in each binary. The module carries Certificate #5247 (FIPS 140-3, Level 1). Because the module ships inside the binary, FIPS compliance doesn't depend on the host, the base image, or an external library such as OpenSSL.

Earlier FIPS builds used Microsoft's fork of Go to link against OpenSSL, which required a Red Hat UBI base image running in FIPS mode. Palo Alto Networks still supports these builds.

FIPS cryptographic modules by version¶

Each Palo Alto Networks FIPS build uses one of the following cryptographic modules:

Some very old FIPS builds used the BoringSSL module (Certificate #3678); none of those releases are supported today, so upgrade to a newer version. For more information on the OpenSSL module, see Red Hat's FIPS compliance page.

FIPS module by component¶

The following table shows which cryptographic module each component's FIPS builds use, by version.

Confirming FIPS compliance¶

Because the cryptographic module is compiled into each binary, Palo Alto Networks FIPS components are FIPS-compliant regardless of the host or base image. They do not require the underlying platform to run in FIPS mode, and they do not panic when run on a non-FIPS host. Confirming a FIPS build is only one step. Full FIPS compliance across your whole environment is a wider task that you're responsible for verifying.

There are two ways to confirm that a component is a FIPS build.

Check the compliance flag¶

All Palo Alto Networks FIPS binaries for these Kubernetes components include a hidden --venafi-fips-enabled flag. Run the binary or container with this flag as its only argument:

<binary> --venafi-fips-enabled

The exit code is the reliable check: 0 means FIPS mode is on, non-zero means it isn't. The command also prints Venafi FIPS: true or false to standard error (redirect with 2>&1 to read it).

A true result confirms FIPS mode is on but not which module provides it: both the validated module (v1.0.0) and a newer, unvalidated one report true. To confirm the validated module, use the next check.

Check the module recorded in the binary¶

FIPS builds are compiled with the Go Cryptographic Module, which is recorded in the binary's build information:

go version -m <binary> | grep GOFIPS140

Non-compliant cryptography¶

A FIPS-validated cryptographic module is not enough to be FIPS-compliant at runtime: you must also use only FIPS-approved algorithms. Some Palo Alto Networks FIPS-compliant components can use non-compliant algorithms if you request them, and access to them is not blocked.

Whether a given algorithm is approved depends on the cryptographic module the component was built with, as described in FIPS cryptographic modules by version. The following guidance applies to builds that use the Go Cryptographic Module, Certificate #5247. Avoid these algorithms where you need to maintain compliance.

Certificate algorithms¶

cert-manager can issue certificates using the following algorithms:

Keystore output formats¶

cert-manager and Trust Manager can write to the following keystore formats:

PKCS#12 and JKS use these algorithms for backwards compatibility, not security. For more information, see the open-source documentation.

FIPS-only TLS¶

Palo Alto Networks FIPS-compliant binaries enforce FIPS-compliant TLS at runtime. In FIPS mode, TLS is restricted to FIPS-approved settings: TLS 1.0 and 1.1 are refused, and non-approved cipher suites — such as ChaCha20-Poly1305 and CBC suites — are unavailable. Only TLS 1.2 and 1.3 with approved cipher suites are allowed.

FIPS builds enable this by shipping with GODEBUG=fips140=on.

You can turn FIPS mode off by setting GODEBUG=fips140=off, which downgrades a FIPS image to standard cryptography. This is a deliberate operator action and makes the component non-compliant.

FIPS container images¶

Palo Alto Networks provides signed FIPS-compliant container images for its Kubernetes components. Images are single-arch (linux/amd64 only) and their names end with -fips.

Image names contain the -fips suffix, but some drop the cert-manager- prefix, for example csi-driver-fips.

Install a FIPS build¶

To install a component's FIPS build, use the FIPS variant of its Helm chart. For example, to install Enterprise Issuer:

VERSION=v0.22.0
helm upgrade demo oci://registry.venafi.cloud/charts/venafi-enhanced-issuer-fips \
    --install \
    --wait \
    --create-namespace \
    --namespace venafi \
    --set global.imagePullSecret[0].name="venafi-image-pull-secret" \
    --version $VERSION

To confirm the correct build is running, check that the pod's container image has the -fips suffix.