Prerequisites

Before deploying Develocity Provenance Governor, ensure you have the following prerequisites. These are organized in a logical order that matches the typical installation workflow: infrastructure setup, external integrations, and security configuration.

Recommended Setup Order:

Infrastructure (set up first):

  1. Develocity License - Required for registry authentication

  2. Deployment Platform - Kubernetes cluster or Docker

  3. Hostname - DNS configuration for ingress (Kubernetes) or reverse proxy (Docker)

  4. TLS Certificate - SSL/TLS for secure access

External Integrations (configure before deployment):

  1. Develocity Instance - Source of build data

  2. Attestation Storage - Artifactory or Amazon S3

Security (prepare before first use):

  1. Signing Key Pair - For attestation signatures

Planning:

  1. Resource Requirements - Review resource requirements

Develocity License

Develocity Provenance Governor uses your existing Develocity license - no separate license is required. Any valid Develocity license works; no special entitlements are needed. If you are already a Develocity customer, you can use your existing license. If you do not have a Develocity license, contact Gradle’s sales team and mention that you need access for "Develocity Provenance Governor".

Deployment Platform

Develocity Provenance Governor is a containerized application. Choose one of the following deployment platforms:

Kubernetes

Deploy to a Kubernetes cluster with an Ingress Controller. This is the recommended approach for production environments with existing Kubernetes infrastructure. See the Kubernetes Deployment Guide.

Docker

Run directly with Docker on any host with Docker Engine installed. This is suitable for environments without Kubernetes, simpler deployments, or local evaluation. See the Docker Deployment Guide.

Resource Requirements

Plan for these resource requirements: the recommended minimum is 2 CPUs and 1 GiB memory per instance. When deploying with Kubernetes, these values are configurable via the Deployment resource. When deploying with Docker, you can set resource limits using docker run --cpus and --memory flags. Lower values may impact performance.

Attestation Storage

Develocity Provenance Governor requires at least one attestation storage backend. You can use Amazon S3, JFrog Artifactory, or both simultaneously. See Attestation Storage Configuration for full configuration details.

Amazon S3

Requirements:

  • An S3 bucket in your preferred AWS region

  • Network access from the Develocity Provenance Governor deployment to the S3 endpoint

  • An IAM principal (user, role, or service account) with the following permissions on the bucket:

    • s3:PutObject - to publish attestations

    • s3:GetObject - to read attestations for policy evaluation

    • s3:ListBucket - to discover attestations during policy evaluation

Authentication can use static credentials, IAM role assumption, or the container credentials provider chain (e.g., IRSA on EKS). See S3 Configuration for details.

JFrog Artifactory with Evidence Management

Artifactory Enterprise+ license (version 7.104.2 or later) is required. The Evidence Management feature is mandatory when using Artifactory as a storage backend.

Requirements:

  • Artifactory version 7.104.2 or later

  • Enterprise+ license

  • Evidence Management feature enabled with support for external evidence

  • Network access from the Develocity Provenance Governor deployment to the Artifactory instance

  • Artifactory Access Token or Identity Token with the following permissions:

    • Read - to retrieve attestations

    • Annotate - to attach evidence metadata to artifacts

Develocity Instance

Develocity Provenance Governor uses Develocity Build Scan data to generate attestations. It requires network access to a Develocity instance.

Develocity Provenance Governor requires a valid Develocity access key for a user with the “Access build data via the API” permission. If the Develocity instance is using Project-level Access Control, Develocity Provenance Governor will only be able to publish attestations for Build Scan data in projects that the user has access to.

The minimum version of Develocity that Develocity Provenance Governor supports is 2023.3. Develocity Provenance Governor supports publishing attestations from Build Scan data from the following build tools:

  • Gradle, with Develocity plugin version 1.16 or later.

    • JVM attestations for Gradle toolchains are only supported for plugin 3.11 or later.

  • Maven, with Develocity extension version 1.4 or later.

We recommend using the latest available version of Develocity and its build tool integrations for the best experience.

Signing Key Pair

Develocity Provenance Governor cryptographically signs all attestations to ensure authenticity and prevent tampering. You need to generate a signing key pair before deployment. The private key remains with Develocity Provenance Governor and is used to sign attestations. The public key is used to verify attestation signatures. If you are using Artifactory, the public key must also be registered in your Artifactory instance.

Supported Key Types:

We support Ed25519, RSA, and Elliptic Curve keys. Ed25519 is recommended because it provides strong security (equivalent to 128-bit security) with significantly smaller keys and faster operations than RSA or ECDSA.

Generating a Key Pair:

Develocity Provenance Governor needs to be configured with a signing key pair in PEM format. You can generate an Ed25519 key pair using OpenSSL:

openssl genpkey -algorithm Ed25519 -out ./key-pair.private-pem
openssl pkey -in ./key-pair.private-pem -pubout -out ./key-pair.public-pem

Keep the private key secure. You’ll configure it during deployment — as a Kubernetes secret or as a file in the secrets configuration directory (for Docker deployments). If using Artifactory, the public key will also be registered there to verify attestation signatures.

Hostname

Develocity Provenance Governor needs a hostname for production use. For Kubernetes deployments, it will be used in the Ingress resource — ensure the hostname’s DNS is configured to work with the cluster’s Ingress Controller. For Docker deployments, configure DNS to point to the host running the container and use a reverse proxy for TLS termination.

TLS Certificate

You’ll need a TLS (Transport Layer Security) certificate for your hostname to enable SSL (Secure Sockets Layer). While SSL/TLS is technically optional, it is strongly recommended for production environments.

Options include:

  • Using an existing organizational certificate

  • Generating one with cert-manager and Let’s Encrypt (see deployment section for details)

  • Using a self-signed certificate for testing (not recommended for production)