Jenkins core: FIPS 140-2 compliant artifacts with caveats

1 minute read

This section describes Jenkins Core artifacts that are FIPS 140-2 compliant, but with caveats. A Jenkins artifact is FIPS 140-2 compliant with caveats if it contains code or libraries that do not adhere to FIPS 140-2 standards. They should not be used in your pipelines and scripts.

Jenkins CLI

Jenkins CLI is not FIPS 140-2 compliant, but the endpoint is compliant. Because of this, it can be called from outside of the FIPS restricted environment. Therefore, the Jenkins CLI has some limitations and caveats that cannot be used to communicate with the Jenkins instance in FIPS.

Jenkins CLI noCertificateCheck option

You should not skip HTTPS certificate checks in Jenkins CLI with noCertificateCheck in a Jenkins environment that is in FIPS mode.

SSH Key Authentication in Jenkins CLI

SSH key authentication loads a private key from a default location (for example, user home directory: .ssh/id_rsa, .ssh/id_dsa, .ssh/identity) that matches a public key that has been configured for the user on Jenkins.

In this scenario, FIPS 140-2 compliance depends on the environment configuration, specifically the type of keys stored in an external file. The provided keys should conform to the FIPS 140-2 standard in order to ensure FIPS compliance of the Jenkins environment.

openSSH key limitations

The openSSH encrypted keys are not FIPS 140-2 compliant unless they are unencrypted and in PEM format. It is recommended that you generate SSH keys using openssl that supports encryption. However, when you use openSSH to generate SSH keys, use the -m PEM option to make the keys FIPS 140-2 compliant.

Proxy configuration

If you configure a credential in the HTTP Proxy Configuration, it should not be used in production as Jenkins does not allow enforcing the connection to a proxy to use TLS.