TLS Protect for Kubernetes now provides hardened FIPS 140-2 compliant versions of cert-manager and add-ons for deployment into secure environments to meet US Government agencies requirements for information security and processing using only FIPS validated cryptographic modules. Venafi experts have closely followed these requirements and maintains compliant versions of cert-manager which is now available for TLS Protect for Kubernetes customers.
cert-manager FIPS compliant requirements
FIPS (Federal Information Processing Standards) is a set of security standards issued by National Institute of Standards (NIST) aimed at regulating the use of computer systems by US government agencies. Within that set, FIPS 140-2 (Security Requirements for Cryptographic Modules) specifies a set of requirements to be met by a component performing cryptographic functions (referred to as a ‘cryptographic module’) within a system that processes sensitive data.
FIPS 140-2 defines four levels of security where the first level is mostly concerned with using FIPS approved algorithms and the last two levels are mostly concerned with physical security mechanisms. A vendor can get a cryptographic module FIPS validated by submitting it for testing in an accredited Cryptographic Module Testing laboratory. If the module is found to be compliant, the vendor will be issued a certificate and the module will be added to a list of FIPS validated modules maintained by NIST.
US government agencies and contractors are required to only use FIPS validated cryptographic modules. NIST recommends that agencies request FIPS validation details from vendors and verify them using the list of validated modules.
To help ensure our customers can use these compliant builds of cert-manager in their preferred environments, we have created compliant versions of cert-manager, as well as add-ons including istio-csr and google-cas-issuer.
FIPS certified cryptographic algorithms
In the particular case of cert-manager, the main concern in regards to FIPS compliance is the use of FIPS certified cryptographic algorithm implementations. cert-manager itself does not implement these algorithms -- it uses the Go standard crypto library which is not FIPS certified. There is however an existing C SSL library - BoringSSL - that contains a FIPS Level 1 certified crypto module BoringCrypto. Upstream Go maintains a dev.boringcrypto branch of Go that swaps the standard crypto library with BoringSSL.
The FIPS compliant cert-manager build uses dev.boringcrypto Go and thus uses the FIPS certified crypto algorithm implementations from BoringCrypto:
- RSA. FIPS validated RSA implementation from BoringCrypto used RSA#2485. FIPS 140-2 also requires the minimum RSA key size to be 1024 bits. The minimum key size allowed by cert-manager is 2048 bits.
- ECDSA. FIPS validated ECDSA implementation from BoringCrypto used ECDSA#1112. FIPS 140-2 also requires the minimum ECDSA curve size to be 112 bits. The minimum curve size allowed by cert-manager is 256 bits.
- HMAC. FIPS certified HMAC implementation from BoringCrypto used HMAC#3011.
Cloud native FIPS compliance using TLS Protect for Kubernetes
Organisations deploying Kubernetes that are working directly with US Government agencies and who are operationalising cert-manager for machine identity automation across production clusters require FIPS compliant builds of cert-manager. TLS Protect for Kubernetes delivers this compliance by incorporating hardened builds of the open source solution which align with the standards required by the National Institute of Standards (NIST). FIPS 140-2 compliance does not just stop with US Government agencies as it is also required by many other governments. It’s also been adopted outside of the public sector in industries where data security is heavily regulated, in particular in the financial services and healthcare sectors.
As Kubernetes adoption increases and clusters spin up across an enterprise, misconfiguration and out-of-date software can present significant operational and security risk. With TLS Protect for Kubernetes, companies can easily achieve operational consistency of these critical software components, with hardened and secure builds of cert-manager that are not only FIPS 140-2 compliant but also signed directly by Venafi. When each individual cluster is running the exact same hardened version of cert-manager, the security posture is improved, since all private and public certificate configurations are proactively managed by TLS Protect for Kubernetes to prevent security vulnerabilities. This gives platform teams certainty and consistency by standardising cert-manager from TLS Protect for Kubernetes across all clusters, whilst meeting important security requirements from InfoSec/Cyber, to head into production with confidence.
- Google CAS Supports cert-manager and TLS Protect for Kubernetes for Cloud Native and Private PKI
- Jetstack’s cert-manager Matures to v1.0 with New Enterprise Support
- CNCF and Open-Source Machine Identities
Learn more about TLS Protect for Kubernetes
TLS Protect for Kubernetes is a comprehensive cloud native machine identity solution for enterprises that are deploying cert-manager across multiple clusters. It is used by platform and security teams for control, configuration and visibility of cert-manager, enabling teams to rapidly secure modern applications for a variety of different use cases, including ingress and service mesh. Using TLS Protect for Kubernetes hardens the organisation’s security posture by building in consistency and security and provides a means to scale cloud native infrastructure with multi-cluster visibility of each machine identity, including alerts for when misconfigurations are detected with remediation advice for SRE teams.