Software supply chain security¶

All Venafi Kubernetes Enterprise images are cryptographically signed so you can be sure that they're actually built by and provided by Venafi.

If using a mirrored version of the images, you can have confidence that the mirror hasn't tampered with the code inside the image.

Public Keys¶

The public key that can be used for signature verification is provided below. It was generated by Venafi on October 15, 2023.

Verify Docker Images¶

To verify the Docker image signatures use cosign verify. For example, to verify the image of Venafi Kubernetes agent:

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

Substitute <latest-version> with the version number of the latest release of Venafi Agent. For example:

cosign verify registry.venafi.cloud/venafi-agent/venafi-agent:v0.1.43 \
  --key ./venafi-enterprise-pubkey.pem \
  --insecure-ignore-tlog

Important

While Venafi signs container images to ensure authenticity and integrity, transparency logs are not always included. This is to balance security with potential information disclosure.

Include the --insecure-ignore-tlog flag with the cosign command to ignore transparency log verification only.

If successful, the command exits with exit code 0 and prints the following output:

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

[
  {
    "critical": {
      "identity": {
        "docker-reference": "registry.venafi.cloud/venafi-agent/venafi-agent"
      },
      "image": {
        "docker-manifest-digest": "sha256:dcab92e8f6e47b9e342caa98e9bba799d5c39d8c612030e8aeb718629a56be99"
      },
      "type": "cosign container image signature"
    },
    "optional": null
  }
]

FIPS Compliance¶

The Venafi components for Kubernetes are standard Go binaries which perform cryptographic operations. Most often, the cryptography used is provided by the Go standard library.

The Go standard library is not FIPS-validated, and so Venafi produce FIPS-compliant versions of open source and enterprise Kubernetes components for customers who require FIPS compliance.

Venafi FIPS builds use Microsoft's fork of Go which provides the ability to link against OpenSSL as a FIPS-validated cryptographic module. This requires the image to be built with a suitable base image which contains OpenSSL, and as such, each FIPS build uses Red Hat's UBI as a base image, configured in "FIPS mode".

Note

The following FIPS versions of Venafi Kubernetes components are built with Microsoft Go:

Approver Policy Enterprise v0.12.0+
CSI driver v0.7.0+
CSI driver for SPIFFE v0.4.1+
cert-manager v1.12.7+
cert-manager v1.13.3+
cert-manager v1.14.0+
Google CAS Issuer 0.7.2+
Istio CSR v0.7.1+
Trust Manager v0.7.1+
Venafi Enhanced Issuer v0.10.1+

For more information, see Red Hat's RHEL 8 OpenSSL FIPS certificate and further details on access.redhat.com.

Component versions earlier those listed above used a different pipeline, with a distinct method of achieving FIPS compliance. Those builds use either the BoringSSL FIPS certificate or an older version of that same certificate.

Confirming FIPS Compliance¶

All Venafi FIPS binaries use the requirefips build tag, which means that the binary will panic on start-up if run outside of a FIPS-compliant environment. This prevents dynamically linking against a non-validated version of OpenSSL.

Since the binaries are packaged in a "FIPS-mode" Red Hat UBI container, they should start if Venafi FIPS container images are used without modification.

In addition, all Venafi FIPS binaries are patched to include a hidden flag to check FIPS compliance.

If the binary or container is run with exactly one argument which matches --venafi-fips-enabled then the program will produce one line of output: Venafi FIPS: <true>|<false> and then exit.

If, when called with only the --venafi-fips-enabled flag, the program prints Venafi FIPS: true and then exits successfully, the container was built with the latest Venafi FIPS pipeline.

Any other behavior with the --venafi-fips-enabled flag means that the program was either built with an old pipeline, or was not built with Venafi FIPS enabled. To remediate, you should check that you're using the latest available versions of Venafi FIPS components.

FIPS Compliance

Venafi ensures that FIPS-compliant components are built to link against a FIPS-validated cryptographic module, but the task of ensuring FIPS compliance across your environment is a wider one which may require modifications to the Kubernetes environment you run, including to the kernels running on your cluster's nodes. Simply using a Venafi FIPS-compliant component might not be enough to achieve all compliance goals, and users are expected to confirm their own compliance independently.

Non-compliant Cryptography¶

Linking against a FIPS-validated cryptographic module is not enough to be FIPS-compliant at runtime. Maintaining compliance requires that you only use FIPS-validated algorithms, and some Venafi FIPS-compliant components are capable of using non-compliant cryptography, if requested.

For example, cert-manager is capable of issuing RSA, ECDSA and EdDSA (Ed25519) certificates, but only RSA and ECDSA are FIPS-approved algorithms in the UBI 8 OpenSSL certificate and issuing an EdDSA certificate would not be compliant.

Access to non-compliant cryptography is not blocked when using FIPS-compliant components.

The following is a list of some non-compliant cryptography in various components, to aid in avoiding use of these algorithms:

cert-manager can issue Ed25519 certificates, which use non-compliant cryptography in current FIPS-builds of cert-manager.
cert-manager can issue ECDSA certificates using P-256, P-384 and P-521. Compliance of each curve may vary, and should be checked before use.
cert-manager can issue RSA certificates with a variety of key sizes. Key sizes should be checked for compliance before use.
cert-manager and Trust Manager can write to PKCS#12 files, which in their default configuration may use non-compliant cryptography. Algorithms for PKCS#12 are chosen for backwards compatibility and not for security and as such outdated algorithms such as RC2 are used by PKCS#12 library.
cert-manager v1.14 and newer includes the profiles option when writing to a PKCS#12 file. The LegacyDES and LegacyRC2 profiles are definitely non-compliant, while the Modern2023 profile may be compliant. Use the Modern2023 profile but ensure that your consumers can read that profile and that the underlying implementation in your specific version of cert-manager remains compliant.
Trust Manager defaults to using passwordless PKCS#12 files but uses the LegacyRC2 encoder, which may use RC2.
The PKCS#12 library used by these components also contains a custom PBKDF implementation which is likely to be non-compliant, if used.
cert-manager and Trust Manager can write to JKS files which may use the SHA-1 hash algorithm which may be non-compliant. As with PKCS#12 files, algorithms used for JKS files are used for backwards compatibility and not for security.

FIPS-only TLS¶

Venafi FIPS-compliant binaries enforce FIPS-compliant TLS at runtime using a 'FIPS only' mode provided by the Microsoft Go fork.

This reduces the number of TLS cipher suites available to include only FIPS-validated algorithms.

Docker Images¶

There are Docker images of FIPS compliant binaries for all the components of Venafi components for Kubernetes. The FIPS compliant Docker images are not multi-arch images and are only suitable for linux/amd64 platforms.

Like the standard images, the FIPS images are digitally signed.

Configure access to the enterprise registry¶

Follow the instructions in Configuring access to enterprise components to enable access to the artifacts required for this component. Use venafi as the namespace.

Use FIPS compliant Docker images¶

You can use the FIPS Docker compliant images by overriding the default image values either by setting values of the Helm chart or by modifying the installation manifests.

Which method you use depends on the component and on your preferred deployment method. Refer to the documentation and Helm chart values of each component.

For example, to install venafi-enhanced-issuer with the FIPS compliant images using Helm:

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

The Chart --version flag must match the image tag version, and verify that the venafi-enhanced-issuer pod container image has a -fips suffix.

Image Names¶

All Venafi FIPS-compliant images end with the -fips suffix.

For example, the non-FIPS cert-manager controller component image is private-registry.venafi.cloud/cert-manager/cert-manager-controller and the FIPS-compliant version is private-registry.venafi.cloud/cert-manager/cert-manager-controller-fips.

Some components have different names as well as the FIPS suffix:

private-registry.venafi.cloud/csi-driver/cert-manager-csi-driver becomes private-registry.venafi.cloud/csi-driver/csi-driver-fips
private-registry.venafi.cloud/csi-driver-spiffe/cert-manager-csi-driver-spiffe becomes private-registry.venafi.cloud/csi-driver-spiffe/csi-driver-spiffe-fips
private-registry.venafi.cloud/csi-driver-spiffe/cert-manager-csi-driver-spiffe-approver becomes private-registry.venafi.cloud/csi-driver-spiffe/csi-driver-spiffe-approver-fips
private-registry.venafi.cloud/istio-csr/cert-manager-istio-csr becomes private-registry.venafi.cloud/istio-csr/istio-csr-fips

Also, while there is a Venafi mirror of the open source approver-policy component at private-registry.venafi.cloud/cert-manager-approver-policy/cert-manager-approver-policy, there is no corresponding FIPS build for approver-policy.

Instead, Approver Policy Enterprise has a FIPS build available at private-registry.venafi.cloud/venafi-approver-policy/approver-policy-enterprise-fips which will work in place of the open source component.