Integrating

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integrations section, select Generic Docker Registry.
3. Click New integration.

4. Enter the details for the following fields:

   1. Integration name: The name of the integration.
   2. Endpoint: The address of the registry.
   3. Username and Password.
5. If you are not using a TLS certificate when connecting to the registry, select Disable TLS certificate validation (insecure).
6. Select Create integration without testing to create the integration without testing the connection to the registry.
7. Select Test to test that the integration with the selected registry is working.
8. Select Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integrations section, select Amazon ECR.
3. Click New integration, or click one of the automatically-generated integrations to open it, then click Edit.

4. Enter or modify the details for the following fields:

   1. Update stored credentials: Clear this box if you are modifying an integration without updating the credentials such as access keys and passwords.
   2. Integration name: The name of the integration.
   3. Registry ID: The ID of the registry.
   4. Endpoint: The address of the registry. This value is required only if you are using a private virtual private cloud (VPC) endpoint for Amazon ECR. This field is not enabled when the AssumeRole option is selected.
   5. Region: The region for the registry; for example, us-west-1.
5. If you are using IAM, select Use Container IAM role. Otherwise, clear the Use Container IAM role box and enter the Access key ID and Secret access key.

6. If you are using AssumeRole authentication, select Use AssumeRole and enter the details for the following fields:

   1. AssumeRole ID: The ID of the role to assume.
   2. AssumeRole External ID (optional): If you are using an external ID with AssumeRole, you can enter it here.
7. Select Create integration without testing to create the integration without testing the connection to the registry.
8. Select Test to test that the integration with the selected registry is working.
9. Select Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integrations section, select Google Container Registry.
3. Click New integration.

4. Enter the details for the following fields:

   1. Integration name: The name of the integration.
   2. Type: Select Registry.
   3. Registry Endpoint: The address of the registry.
   4. Project: The Google Cloud project name.
   5. Use workload identity: Check to authenticate using a workload identity.
   6. Service account key (JSON): Your service account key for authentication.
5. Select Create integration without testing to create the integration without testing the connection to the registry.
6. Select Test to test that the integration with the selected registry is working.
7. Select Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integrations section, select Google Artifact Registry.
3. Click New integration.

4. Enter the details for the following fields:

   1. Integration name: The name of the integration.
   2. Registry endpoint: The address of the registry.
   3. Project: The Google Cloud project name.
   4. Use workload identity: Check to authenticate using a workload identity.
   5. Service account key (JSON): Your service account key for authentication.
5. Select Create integration without testing to create the integration without testing the connection to the registry.
6. Select Test to test that the integration with the selected registry is working.
7. Select Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integrations section, select Microsoft Azure Container Registry.
3. Click New integration.

4. Enter the details for the following fields:

   1. Integration name: The name of the integration.
   2. Endpoint: The address of the registry.
   3. Username and Password.
5. Select Create integration without testing to create the integration without testing the connection to the registry.
6. Select Test to test that the integration with the selected registry is working.
7. Select Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integrations section, select JFrog Artifactory.
3. Click New integration.

4. Enter the details for the following fields:

   1. Integration name: The name of the integration.
   2. Endpoint: The address of the registry.
   3. Username and Password.
5. If you are not using a TLS certificate when connecting to the registry, select Disable TLS certificate validation (insecure).
6. Select Create integration without testing to create the integration without testing the connection to the registry.
7. Select Test to test that the integration with the selected registry is working.
8. Select Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integrations section, select Red Hat Quay.io.
3. Click New integration.
4. Enter the Integration name.

5. Enter the Endpoint, or the address of the registry.

   1. If you are integrating with the Quay public repository, under Type, select Registry, and then go to the next step.

   2. If you are integrating with a Quay private registry, under Type, select Registry and enter information in the following fields:

      • Robot username: If you are accessing the registry by using a Quay robot account, enter the user name in the format <namespace>+<accountname>.
      • Robot password: If you are accessing the registry by using a Quay robot account, enter the password for the robot account user name.
      • OAuth token: If you are accessing the registry by using an OAuth token (deprecated), enter it in this field.
6. Optional: If you are not using a TLS certificate when connecting to the registry, select Disable TLS certificate validation (insecure).
7. Optional: To create the integration without testing, select Create integration without testing.
8. Select Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Use global search to search for Lifecycle Stage:Build.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Click + New Policy.
3. Enter the Name for the policy.
4. Select a Severity level for the policy: Critical, High, Medium, or Low.

5. Choose the Lifecycle Stages for which the policy is applicable, from Build, Deploy, or Runtime. You can select more than one stage.

   Note

   If you create a new policy for integrating with a CI system, select Build as the lifecycle stage.

   • Build-time policies apply to image fields such as CVEs and Dockerfile instructions.
   • Deploy-time policies can include all build-time policy criteria. They can also have data from your cluster configurations, such as running in privileged mode or mounting the Docker daemon socket.
   • Runtime policies can include all build-time and deploy-time policy criteria, and data about process executions during runtime.
6. Enter information about the policy in the Description, Rationale, and Remediation fields. When CI validates the build, the data from these fields is displayed. Therefore, include all information explaining the policy.
7. Select a category from the Categories drop-down menu.

8. Select a notifier from the Notifications drop-down menu that receives alert notifications when a violation occurs for this policy.

   Note

   You must integrate RHACS with your notification providers, such as webhooks, Jira, or PagerDuty, to receive alert notifications. Notifiers only show up if you have integrated any notification providers with RHACS.

9. Use Restrict to Scope to enable this policy only for a specific cluster, namespace, or label. You can add multiple scopes and also use regular expressions in RE2 Syntax for namespaces and labels.
10. Use Exclude by Scope to exclude deployments, clusters, namespaces, and labels. This field indicates that the policy will not apply to the entities that you specify. You can add multiple scopes and also use regular expressions in RE2 Syntax for namespaces and labels. However, you cannot use regular expressions for selecting deployments.

11. For Excluded Images (Build Lifecycle only), select all the images from the list for which you do not want to trigger a violation for the policy.

    Note

    The Excluded Images (Build Lifecycle only) setting only applies when you check images in a continuous integration system (the Build lifecycle stage). It does not have any effect if you use this policy to check running deployments (the Deploy lifecycle stage) or runtime activities (the Runtime lifecycle stage).

12. In the Policy Criteria section, configure the attributes that will trigger the policy.
13. Select Next on the panel header.
14. The new policy panel shows a preview of the violations that are triggered if you enable the policy.
15. Select Next on the panel header.

16. Choose the enforcement behavior for the policy. Enforcement settings are only available for the stages that you selected for the Lifecycle Stages option. Select ON to enforce policy and report a violation. Select OFF to only report a violation.

    Note

    The enforcement behavior is different for each lifecycle stage.

    • For the Build stage, RHACS fails your CI builds when images match the conditions of the policy.

    • For the Deploy stage, RHACS blocks the creation and update of deployments that match the conditions of the policy if the RHACS admission controller is configured and running.

      • In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. In other clusters, RHACS edits noncompliant deployments to prevent pods from being scheduled.
      • For existing deployments, policy changes only result in enforcement at the next detection of the criteria, when a Kubernetes event occurs. For more information about enforcement, see "Security policy enforcement for the deploy stage".
    • For the Runtime stage, RHACS stops all pods that match the conditions of the policy.
    Warning

    Policy enforcement can impact running applications or development processes. Before you enable enforcement options, inform all stakeholders and plan how to respond to the automated enforcement actions.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the Image Integration section, look for highlighted Registry tiles. The tiles also list the number of items already configured for that tile.

Procedure

1. After you have generated the authentication token, export it as the ROX_API_TOKEN variable by entering the following command:

   $ export ROX_API_TOKEN=<api_token>

2. (Optional): You can also save the token in a file and use it with the --token-file option by entering the following command:

   $ roxctl central debug dump --token-file <token_file>

Procedure

1. Log in to the registry.redhat.io registry.

   $ docker login registry.redhat.io

2. Pull the latest container image for the roxctl CLI.

   $ docker pull registry.redhat.io/advanced-cluster-security/rhacs-roxctl-rhel8:4.6.1

Procedure

1. Log in to CircleCI and open an existing project or create a new project.
2. Click Project Settings.
3. Click Environment variables.

4. Click Add variable and create the following three environment variables:

   • Name: STACKROX_CENTRAL_HOST - The DNS name or IP address of Central.
   • Name: ROX_API_TOKEN - The API token to access Red Hat Advanced Cluster Security for Kubernetes.
   • Name: DOCKERHUB_PASSWORD - The password for your Docker Hub account.
   • Name: DOCKERHUB_USER - The username for your Docker Hub account.
5. Create a directory called .circleci in the root directory of your local code repository for your selected project, if you do not already have a CircleCI configuration file.

6. Create a config.yml configuration file with the following lines in the .circleci directory:

   version: 2
   jobs:
     check-policy-compliance:
       docker:
         - image: 'circleci/node:latest'
           auth:
             username: $DOCKERHUB_USER
             password: $DOCKERHUB_PASSWORD
       steps:
         - checkout
         - run:
             name: Install roxctl
             command: |
                 curl -H "Authorization: Bearer $ROX_API_TOKEN" https://$STACKROX_CENTRAL_HOST:443/api/cli/download/roxctl-linux -o roxctl && chmod +x ./roxctl
         - run:
             name: Scan images for policy deviations and vulnerabilities
             command: |
                 ./roxctl image check --endpoint "$STACKROX_CENTRAL_HOST:443" --image "<your_registry/repo/image_name>" 1
         - run:
             name: Scan deployment files for policy deviations
             command: |
                 ./roxctl image check --endpoint "$STACKROX_CENTRAL_HOST:443" --image "<your_deployment_file>" 2
                 # Important note: This step assumes the YAML file you'd like to test is located in the project.
   workflows:
     version: 2
     build_and_test:
       jobs:
         - check-policy-compliance

   1

   Replace <your_registry/repo/image_name> with your registry and image path.

   2

   Replace <your_deployment_file> with the path to your deployment file.

   Note

   If you already have a config.yml file for CircleCI in your repository, add a new jobs section with the specified details in your existing configuration file.

7. After you commit the configuration file to your repository, go to the Jobs queue in your CircleCI dashboard to verify the build policy enforcement.

Procedure

1. After you configure incoming webhooks, add an annotation similar to the following in your deployment YAML file:

   example.com/slack-webhook: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

2. Use the annotation key example.com/slack-webhook in the Label/Annotation Key For Slack Webhook field when you configure Red Hat Advanced Cluster Security for Kubernetes.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Under the External backups section, click Google Cloud Storage.
3. Select the integration name for the GCS bucket in which you want to do a backup.
4. Click Trigger Backup.

Procedure

1. In your Splunk dashboard, go to Settings → Add Data.
2. Click Monitor.
3. On the Add Data page, click HTTP Event Collector.
4. Enter a Name for the event collector and then click Next >.
5. Accept the default Input Settings and click Review >.
6. Review the event collector properties and click Submit >.
7. Copy the Token Value for the event collector. You need this token value to configure integration with Splunk in Red Hat Advanced Cluster Security for Kubernetes.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Scroll down to the Notifier Integrations section and select Splunk.
3. Click New Integration (add icon).
4. Enter a name for Integration Name.
5. Enter your Splunk URL in the HTTP Event Collector URL field. You must specify the port number if it is not 443 for HTTPS or 80 for HTTP. You must also add the URL path /services/collector/event at the end of the URL. For example, https://<splunk-server-path>:8088/services/collector/event.

6. Enter your token in the HTTP Event Collector Token field.

   Note

   If you are using Red Hat Advanced Cluster Security for Kubernetes version 3.0.57 or newer, you can specify custom Source Type for Alert events and Source Type for Audit events.

7. Select Test to send a test message to verify that the integration with Splunk is working.
8. Select Create to generate the configuration.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Select one or more policies for which you want to send alerts.
3. Under Bulk actions, select Enable notification.

4. In the Enable notification window, select the Splunk notifier.

   Note

   If you have not configured any other integrations, the system displays a message that no notifiers are configured.

5. Click Enable.

Procedure

1. Download the Red Hat Advanced Cluster Security for Kubernetes add-on from Splunkbase.
2. Go to the Splunk home page on your Splunk instance.
3. Go to Apps → Manage Apps.
4. Select Install app from file.
5. In the Upload app pop-up box, select Choose File and select the Red Hat Advanced Cluster Security for Kubernetes add-on file.
6. Click Upload.
7. Click Restart Splunk, and confirm to restart.
8. After Splunk restarts, select Red Hat Advanced Cluster Security for Kubernetes from the Apps menu.

9. Go to Configuration and then click Add-on Settings.

   1. For Central Endpoint, enter the IP address or the name of your Central instance. For example, central.custom:443.
   2. Enter the API token you have generated for the add-on.
   3. Click Save.
10. Go to Inputs.

11. Click Create New Input, and select one of the following:

    • ACS Compliance to pull the compliance data.
    • ACS Violations to pull the violations data.
    • ACS Vulnerability Management to pull the vulnerabilities data.
12. Enter a Name for the input.
13. Select an Interval to pull data from Red Hat Advanced Cluster Security for Kubernetes. For example, every 14400 seconds.
14. Select the Splunk Index to which you want to send the data.
15. For Central Endpoint, enter the IP address or the name of your Central instance.
16. Enter the API token you have generated for the add-on.
17. Click Add.

Procedure

1. Click Update on the update notification.
2. Select the checkbox for accepting the terms and conditions, and then click Accept and Continue to install the update.
3. After the installation, select Red Hat Advanced Cluster Security for Kubernetes from the Apps menu.

4. Go to Configuration and then click Add-on Settings.

   1. Enter the API token you have generated for the add-on.
   2. Click Save.

Procedure

1. Add an annotation similar to the following example in your namespace or deployment YAML file:

   annotations:
   # ...
     jira/project-key: <jira_project_key>
   # ...

2. Use the annotation key jira/project-key in the Annotation key for project field when you configure Red Hat Advanced Cluster Security for Kubernetes.

Procedure

1. While configuring Jira integration in Red Hat Advanced Cluster Security for Kubernetes, turn on the Priority Mapping toggle. Red Hat Advanced Cluster Security for Kubernetes gets the JIRA project schema, and auto fills the values for the CRITICAL_SEVERITY, HIGH_SEVERITY, MEDIUM_SEVERITY, and LOW_SEVERITY fields.
2. Verify or update the priority values based on your JIRA project configuration.
3. Select Test to test that the integration with Jira is working.
4. Select Create to generate the configuration.

Procedure

1. Go to Platform Configuration → Integrations.
2. Under the Notifier Integrations section, select Email.
3. Select New Integration.
4. In the Integration name field, enter a name for your email integration.
5. In the Email server field, enter the address of your email server. The email server address includes fully qualified domain name (FQDN) and the port number; for example, smtp.example.com:465.

6. Optional: If you are using unauthenticated SMTP, select Enable unauthenticated SMTP. This is insecure and not recommended, but might be required for some integrations. For example, you might need to enable this option if you use an internal server for notifications that does not require authentication.

   Note

   You cannot change an existing email integration that uses authentication to enable unauthenticated SMTP. You must delete the existing integration and create a new one with Enable unauthenticated SMTP selected.

7. Enter the user name and password of a service account that is used for authentication.
8. Optional: Enter the name that you want to appear in the FROM header of email notifications in the From field; for example, Security Alerts.
9. Specify the email address that you want to appear in the SENDER header of email notifications in the Sender field.
10. Specify the email address that will receive the notifications in the Default recipient field.

11. Optional: Enter an annotation key in Annotation key for recipient. You can use annotations to dynamically determine an email recipient. To do this:

    1. Add an annotation similar to the following example in your namespace or deployment YAML file, where email is the Annotation key that you specify in your email integration. You can create an annotation for the deployment or the namespace.

       annotations:
         email: <email_address>

    2. Use the annotation key email in the Annotation key for recipient field.

       If you configured the deployment or namespace with an annotation, the RHACS sends the alert to the email specified in the annotation. Otherwise, it sends the alert to the default recipient.

       Note

       The following rules govern how RHACS determines the recipient of an email notification:

       • If the deployment has an annotation key, the annotation’s value overrides the default value.
       • If the namespace has an annotation key, the namespace’s value overrides the default value.
       • If a deployment has an annotation key and a defined audience, RHACS sends an email to the audience specified in the key.
       • If a deployment does not have an annotation key, RHACS checks the namespace for an annotation key and sends an email to the specified audience.
       • If no annotation keys exist, RHACS sends an email to the default recipient.

12. Optional: Select Disable TLS certificate validation (insecure) to send email without TLS. You should not disable TLS unless you are using StartTLS.

    Note

    Use TLS for email notifications. Without TLS, all email is sent unencrypted.

13. Optional: To use StartTLS, select either Login or Plain from the Use STARTTLS (requires TLS to be disabled) drop-down menu.

    Important

    With StartTLS, credentials are passed in plain text to the email server before the session encryption is established.

    • StartTLS with the Login parameter sends authentication credentials in a base64 encoded string.
    • StartTLS with the Plain parameter sends authentication credentials to your mail relay in plain text.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Select one or more policies for which you want to send alerts.
3. Under Bulk actions, select Enable notification.

4. In the Enable notification window, select the Email notifier.

   Note

   If you have not configured any other integrations, the system displays a message that no notifiers are configured.

5. Click Enable.

Procedure

1. Go to Platform Configuration → Integrations.
2. Under the Notifier Integrations section, select RHACS Cloud Service Email.
3. Select New Integration.
4. In the Integration name field, enter a name for your email integration.
5. Specify the email address to which you want to send the email notifications in the Default recipient field.

6. Optional: Enter an annotation key in Annotation key for recipient. You can use annotations to dynamically determine an email recipient. To do this:

   1. Add an annotation similar to the following example in your namespace or deployment YAML file, where email is the Annotation key that you specify in your email integration. You can create an annotation for the deployment or the namespace.

      annotations:
        email: <email_address>

   2. Use the annotation key email in the Annotation key for recipient field.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Select one or more policies for which you want to send alerts.
3. Under Bulk actions, select Enable notification.

4. In the Enable notification window, select the RHACS Cloud Service Email notifier.

   Note

   If you have not configured any other integrations, the system displays a message that no notifiers are configured.

5. Click Enable.

Procedure

1. Run the following command to enable the IAM OpenID Connect (OIDC) provider for your EKS cluster:

   $ eksctl utils associate-iam-oidc-provider --cluster <cluster_name> --approve

2. Create an IAM role for your EKS cluster.

3. Edit the permission policy of the role and grant the permissions required by the integration. For example:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "VisualEditor0",
               "Effect": "Allow",
               "Action": [
                   "ecr:BatchCheckLayerAvailability",
                   "ecr:BatchGetImage",
                   "ecr:DescribeImages",
                   "ecr:DescribeRepositories",
                   "ecr:GetAuthorizationToken",
                   "ecr:GetDownloadUrlForLayer",
                   "ecr:ListImages"
               ],
               "Resource": "arn:aws:iam::<ecr_registry>:role/<role_name>"
           }
       ]
   }

4. Update the trust relationship for the role that you want to assume:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": [
             "arn:aws:iam::<ecr-registry>:role/<role_name>" 1
           ]
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }

   1

   The <role_name> should match with the new role that you have created in earlier steps.

5. Enter the following command to associate the newly created role with a service account:

   $ oc -n stackrox annotate sa central eks.amazonaws.com/role-arn=arn:aws:iam::67890:role/<role_name> 1

   1

   If you use Kubernetes, enter kubectl instead of oc.

6. Enter the following command to restart the Central pod and apply the changes:

   $ oc -n stackrox delete pod -l "app in (central,sensor)" 1

   1

   If you use Kubernetes, enter kubectl instead of oc.

Procedure

1. Follow the instructions at Creating OpenID Connect (OIDC) identity providers to create web identity of the OpenShift Container Platform cluster. Use openshift as the value for Audience.
2. Create an IAM role for the web identity of the OpenShift Container Platform cluster.

3. Edit the permission policy of the role and grant the permissions required by the integration. For example:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "VisualEditor0",
               "Effect": "Allow",
               "Action": [
                   "ecr:BatchCheckLayerAvailability",
                   "ecr:BatchGetImage",
                   "ecr:DescribeImages",
                   "ecr:DescribeRepositories",
                   "ecr:GetAuthorizationToken",
                   "ecr:GetDownloadUrlForLayer",
                   "ecr:ListImages"
               ],
               "Resource": "arn:aws:iam::<ecr_registry>:role/<role_name>"
           }
       ]
   }

4. Update the trust relationship for the role that you want to assume:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "<oidc_provider_arn>"
               },
               "Action": "sts:AssumeRoleWithWebIdentity",
               "Condition": {
                   "StringEquals": {
                       "<oidc_provider_name>:aud": "openshift"
                   }
               }
           }
       ]
   }

5. Set the following RHACS environment variables on the Central or Sensor deployment:

   AWS_ROLE_ARN=<role_arn>
   AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/openshift/serviceaccount/token

Procedure

1. Follow the instructions in the Google Cloud Platform documentation to Use workload identity federation for GKE.

2. Annotate the RHACS service account by running the following command:

   $ oc annotate serviceaccount \ 1
       central \ 2
       --namespace stackrox \
       iam.gke.io/gcp-service-account=<GSA_NAME>@<GSA_PROJECT>.iam.gserviceaccount.com

   1

   If you use Kubernetes, enter kubectl instead of oc.

   2

   When setting up delegated scanning, use sensor instead of central.

Procedure

1. Follow the instructions at Manage workload identity pools to create a workload identity pool. For example:

   $ gcloud iam workload-identity-pools create rhacs-pool \
       --location="global" \
       --display-name="RHACS workload pool"

2. Follow the instructions at Manage workload identity pool providers to create a workload identity pool provider. For example:

   $ gcloud iam workload-identity-pools providers create-oidc rhacs-provider \
       --location="global" \
       --workload-identity-pool="rhacs-pool" \
       --display-name="RHACS provider" \
       --attribute-mapping="google.subject=assertion.sub" \
       --issuer-uri="https://<oidc_configuration_url>" \
       --allowed-audiences=openshift

3. Connect a Google service account to the workload identity pool. For example:

   $ gcloud iam service-accounts add-iam-policy-binding <GSA_NAME>@<GSA_PROJECT>.iam.gserviceaccount.com \
       --role roles/iam.workloadIdentityUser \
       --member="principal://iam.googleapis.com/projects/<GSA_PROJECT_NUMBER>/locations/global/workloadIdentityPools/rhacs-provider/subject/system:serviceaccount:stackrox:central" 1

   1

   For delegated scanning, set the subject to system:serviceaccount:stackrox:sensor.

4. Create a service account JSON containing the Security token service (STS) configuration. For example:

   {
     "type": "external_account",
     "audience": "//iam.googleapis.com/projects/<GSA_PROJECT_ID>/locations/global/workloadIdentityPools/rhacs-pool/providers/rhacs-provider",
     "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
     "token_url": "https://sts.googleapis.com/v1/token",
     "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<GSA_NAME>@<GSA_PROJECT>.iam.gserviceaccount.com:generateAccessToken",
     "credential_source": {
       "file": "/var/run/secrets/openshift/serviceaccount/token",
       "format": {
         "type": "text"
       }
     }
   }

5. Use the service account JSON as a secret to the RHACS namespace:

   apiVersion: v1
   kind: Secret
   metadata:
     name: gcp-cloud-credentials
     namespace: stackrox
   data:
     credentials: <base64_encoded_json>