Configure the Pipeline Maven API plugin for FIPS compliance

To build Apache Maven™ projects as part of the CloudBees Assurance Program (CAP), CloudBees CI on modern cloud platforms includes the Pipeline Maven API (pipeline-maven-api) plugin that includes a set of features and default configuration settings for Apache Maven builds.

Apache Maven builds use the default JDK provided by the node. However, to make the plugin FIPS 140-2 compliant, the JDK installation is modified but without additional configuration the build will fail.

This page provides the following configuration options administrators can use to make the plugin compliant in a FIPS 140-2 environment.

CloudBees cannot guarantee FIPS 140-2 compliance of an external JDK, Apache Maven distribution, and any of the Maven plugins downloaded or used during Apache Maven builds.

Apache Maven build with minimal default configuration using default JDK

Use the following example to configure an Apache Maven build using the default JDK configuration in a FIPS 140-2 environment.

With this configuration, the Apache Maven build uses the FIPS modified JDK. CloudBees cannot guarantee the Apache Maven API plugin supports this configuration.

pipeline {
  agent any
  stages {
    stage("Build") {
      steps {
          git url: 'https://github.com/olamy/simple-spring-boot-servlet'
          withMaven(
	// Maven installation declared in the Jenkins "Global Tool Configuration"
            maven: 'maven-3',
            mavenOpts: '-Xbootclasspath/a:/usr/share/jenkins/fips/bc-fips.jar:/usr/share/jenkins/fips/bctls-fips.jar:/usr/share/jenkins/fips/bcpkix-fips.jar:/usr/share/jenkins/fips/fips-security-manager.jar -Dorg.bouncycastle.fips.approved_only=true -Djava.security.manager=com.cloudbees.cbci.fips_security_manager.FIPSSecurityManager -Djavax.net.ssl.trustStoreType=PKCS12 -Dcom.redhat.fips=false'
          ) {
	// Run the build
            sh "mvn clean verify -e -B"
          }
      }
    }
  }
}▼

Apache Maven build using external JDK

Instead of using the default configuration provided in the FIPS 140-2 compliant JDK, you can configure another JDK for the Apache Maven build in $JENKINS_URL/manage/configureTools/ directory or on the Tool configuration page in the UI.

Use the following example to configure an external JDK in the $JENKINS_URL/manage/configureTools/ directory.

pipeline {
  agent any
  stages {
    stage("Build") {
      steps {
          git url: 'https://github.com/olamy/simple-spring-boot-servlet'
          withMaven(
            jdk: 'jdk17',
            maven: 'maven-3.9.x'
          ) {
            sh "mvn clean verify -e -B"
          }
      }
    }
  }
}▼

In the UI, select Manage Jenkins Tools to access the Tool configuration page. On the Tool configuration page, navigate to the JDK installations section.

Figure 1. Configure external JDK
1. Enter the name of the JDK.
2. Select Install automatically to let Jenkins install the JDK tool on demand. Add Extract*.zip/*.tar.gz as the installer that downloads a tool archive and installs it within Jenkins’s working directory.
3. Enter the URL that will download the tool in binary form. It should be either a ZIP or GZip-compressed TAR file.
4. Enter an optional subdirectory of the downloaded and unpacked archive to use as the tool’s home directory.

The Apache Maven build does not use the FIPS modified JDK in this configuration. Therefore, CloudBees cannot guarantee the JDK is FIPS compliant.

Apache Maven build using the inline YAML node definition

Use the following example of an inline YAML embedded within the Jenkinsfile. The Jenkinsfile contains the definition of another container to run the Apache Maven build.

pipeline {
  agent {
    kubernetes {
      defaultContainer 'jnlp'
      yaml """
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: maven
    // can be adjusted to the version needed or any other image
    image: maven:3.9.8-eclipse-temurin-17
    command:
    - sleep
    - 999999999
    tty: true
"""
    }
  }
  stages {
    stage("Build") {
      steps {
       // Tell the pipeline to run the build within the maven container
       // no need to define jdk and Apache Maven as the default provided by the container will be used
        container('maven') {
          git url: 'https://github.com/olamy/simple-spring-boot-servlet'
          withMaven(
            mavenLocalRepo: '.repository'
          ) {
            sh "mvn clean verify -e -B"
          }
        }
      }
    }
  }
}▼

The Apache Maven build does not use the FIPS modified JDK in this configuration. Therefore, CloudBees cannot guarantee the JDK is FIPS compliant.

Apache Maven build using predefined agents via the Kubernetes POD template

Generate the Apache Maven build by defining the Kubernetes POD templates in the $JENKINS_URL/manage/kubernetesPodTemplates/ directory or the UI.

Use the following example to define the Kubernetes POD template in the $JENKINS_URL/manage/kubernetesPodTemplates/ directory to generate the Apache Maven build.

pipeline {
  agent { node { label 'mvn-build' } }
  stages {
    stage("Build") {
      steps {
        container('maven') {
          git url: 'https://github.com/olamy/simple-spring-boot-servlet'
          withMaven(
            mavenLocalRepo: '.repository'
          ) {
            sh "mvn clean verify -e -B"
          }
        }
      }
    }
  }
}▼

In the UI, select Manage Jenkins Kubernetes Pod Templates Add a pod template to define the Kubernetes Pod template.

Figure 2. Define Kubernetes pod template

Enter the name that defines the pod template.
Add labels to put on the created agents.
Select Only build jobs with label expressions matching this node.
Enter the name for the container to be run.
Enter the container image (repository, name, and tag) for a Jenkins inbound agent.
Select Create.

Apache Maven considerations

Apache Maven plugins can access external resources using non-TLS protocols or non-FIPS compliant hashing or encryption algorithms.

As shown in the example below, a configuration from the Config File Provider plugin (config-file-provider) that uses the HTTP mirror sends authorization credentials over HTTP.

<settings>
  <servers>
    <server>
      <id>release-http-unblocker</id>
      <username>uid</username>
      <password>somerandompassword</password>
    </server>
  </servers>
  <mirrors>
    <mirror> (1)
      <id>release-http-unblocker</id>
      <mirrorOf>central</mirrorOf>
      <name></name>
      <url>http://my-url/libs-release</url>
     </mirror>
  <mirrors>
</settings>▼

1	The HTTP `mirror` setting that sends authorization credentials over HTTP.

Some extensions, such as the Apache Maven build cache extension, may upload data over an HTTP network that exposes the credentials of a non-TLS protocol. The following examples show extensions that expose credentials of a non-TLS protocol.

Remote build cache setup

<remote enabled="true" id="my-cache">
    <url>http://your-buildcache-url</url>
</remote>▼

Credentials setup from settings.xml

<servers>
    <server>
        <id>my-cache</id>
        <username>[cache user]</username>
        <password>[cache password]</password>
    </server>
</servers>▼