Maven with Google Artifact Registry - Host Rule Implementation

Introduction

This guide provides step-by-step instructions for setting up our repository integrations to work with your private Maven package repositories hosted in Google Artifact Registry. Authentication for these private repositories is achieved through service accounts with Base64 encoded JSON keys. By following these steps, you'll enable our repo integrations to scan your private Maven packages for vulnerabilities and ensure compliance with your security policies.

Prerequisites

To set up host rules for Google Artifact Registry, an administrator must have access to Google IAM to create a Service user. A few Maven repositories will also have to be created:

• Maven Standard Repository - For hosting private packages

• Maven Remote Repository - For an upstream to Maven Central

• Maven Virtual Repository - For access to both repositories from one URL. Add both of the above repositories as upstream repositories.

Steps

Create a Service User

To create a Service User in Google Artifact Registry:

• Go to IAM → Service Accounts → Create Service Account

• Service Account Name: Mend Bot

• Service Account ID: mendbot

• Click Create and Continue

• Role: Artifact Registry Service Agent

• Finish the setup process keeping defaults

Create a Key for the Service User

• Go to IAM → Service Accounts → Your service user and click Keys.

• Add Key → Create New Key → JSON

Encrypt your JSON Token

Once the JSON token has been downloaded, encode it as Base64:

1. Windows

   1. certutil -encode key.json tmp.b64 && findstr /v /c:- tmp.b64 > json_key.b64

2. Linux

   1. base64 key.json > json_key.b64

3. MacOS

   1. base64 -i key.json -o json_key.b64

Once the JSON file has been encoded as Base64, then copy the contents of the resulting file into your clipboard and continue with the appropriate Repository Integration Environment.

For Mend-Hosted Repository Integrations (Github.com , Bitbucket Cloud, and Azure Repos)

1. Navigate to our Mend's Repository Integration Secrets Encryption page

2. Each secret you encrypt must be scoped to a GitHub org, Bitbucket Cloud Workspace, or Azure project, and its use will be restricted to those within the app. There are the following fields on the encryption page:

   1. Organization\Group - required; your GitHub org, Bitbucket Cloud Workspace, or your Azure project to which secrets are to be scoped

   2. Repository - optional; your GitHub or Azure repository to which secrets are to be scoped

   3. Raw value - required; your JFrog token that was created earlier in Option 1, or your JFrog password from Option 2

3. Click on Encrypt. This will create an encrypted value, which is the result of the encryption to be used in the integration

4. Copy this encrypted value

For Self-Hosted Repository Integrations (GitHub Enterprise, Bitbucket Server and Data Center, and GitLab)

Follow the steps outlined below to generate encryption for each of the Self-Hosted repo integrations:

• Mend for GitHub Enterprise | Handling Private Registries and Authenticated Repositories

• Mend for Bitbucket Server and Data Center | Handling Private Registries and Authenticated Repositories

• Installing Mend for GitLab | Handling Private Registries and Authenticated Repositories

1. When generating a secret, there are the following fields on the encryption page:

   1. Organization\Group - required; your GitHub org, GitLab group, or Bitbucket group to which secrets are to be scoped

   2. Repository - optional; your repository to which secrets are to be scoped

   3. Raw value - required; your JFrog token that was created earlier in Option 1, or your JFrog password from Option 2

2. Click on Encrypt. This will create an encrypted value, which is the result of the encryption to be used in the integration

3. Copy this encrypted value

WARNING: The Repository value is important based on where you would like to store the credentials. If the credentials are going to be stored in a global configuration's repo-config.json file, then this value should not be used. If it will be stored in a repository’s .whitesource file, then this value should be used.

Applying the Host Rules

NOTE: For more information on authenticating to Google Artifact Registry, please refer to their documentation here: https://cloud.google.com/artifact-registry/docs/java/authentication

Within your repo-config.json (if you have a global setup) or, in your .whitesource file (if you are configuring at the repo level), include the following settings:

• matchHost - The URL of the Google Artifact Registry repository where your Maven packages are located. NOTE: You should have one rule for each Google Artifact Registry repository where your Maven packages are located as they appear in your settings.xml file - meaning there can be multiple hostRules.

  • Format: https://<region>-maven.pkg.dev/<project-id>/<repository>

• hostType - maven

• userName - _json_key_base64

• password - The encrypted value that was generated.

For the hostRules to also work with Remediate/Renovate, add the following “packageRules” settings:

• matchManagers - maven

• registryUrls - https://<region>-maven.pkg.dev/project-id/<repository>

Example:

{
  "hostRules": [
    {
      "matchHost": "https://<region>-maven.pkg.dev/project-id-123456/virtual-maven-repo",
      "hostType": "maven",
      "userName": "_json_key_base64",
      "encrypted": {
        "password": "p278djfdsi9832jnfdshufwji2r389fdskj........."
      }
    }
  ],
  "packageRules": [
    {
      "matchManagers": [ "maven" ],
      "registryUrls": [
        "https://<region>-maven.pkg.dev/project-id-123456/virtual-maven-repo"
      ]
    }
  ]
}