Deploying ScanCentral SAST in Kubernetes

This document describes how to configure and use the scancentral-sast 25.2 Helm chart for ScanCentral SAST components in Kubernetes. You can find the ScanCentral SAST Helm chart at https://hub.docker.com/r/fortifydocker/helm-scancentral-sast.

Table of contents

• Kubernetes versions
• Tool prerequisites
• Installation
• Upgrading
• Troubleshooting

Kubernetes versions

These charts were tested using the following Kubernetes versions:

• Kubernetes 1.30
• Kubernetes 1.31
• Kubernetes 1.32

Tool prerequisites

• kubectl v1.32.x
• helm v3.17.x
• Java keytool utility

OpenText recommends that you use the same tool versions to avoid unpredictable results.

Installation

The following instructions are for example purposes and are based on a default Kubernetes environment running under Linux, using the default namespace. Windows systems might require different syntax for certain commands and other Kubernetes Cluster providers might require additional/different configurations. Your Kubernetes administrator may require the use of specific namespaces and/or other configuration adjustments.

Installation prerequisites

• A working Kubernetes cluster
• A Fortify Software Security Center 25.2 server with user accounts with access to Fortify ScanCentral SAST
• A Fortify license file

Installation steps

1. Creating an image pull secret
2. Creating certificates and required Kubernetes secrets
3. Installing ScanCentral SAST components
4. Verifying that the ScanCentral SAST API is available
5. Integrating ScanCentral SAST with Fortify Software Security Center
6. Special Considerations for testing environments

Creating an image pull secret

By default, the Fortify ScanCentral SAST components Helm chart references its images directly from DockerHub. For Kubernetes to properly install your images using the default configuration, you must create an image pull secret and store it in your installation namespace in Kubernetes. If you are replicating these images to a local repository, you can skip this task and update the relevant image values in the Helm chart to reference your local repository. To create an image pull secret:

• Use the kubectl create secret command as shown in the following code sample:

  kubectl create secret docker-registry docker.io \
   --docker-server=registry-1.docker.io \
   --docker-username='<docker username>' \ 
   --docker-password='<docker password>' \
   --docker-email='<docker user email>'

Creating a secret to store ScanCentral client authentication secrets

ScanCentral SAST requires a secret to store the ScanCentral client authentication secrets. The secret name is specified in the values file.

• Use the kubectl create secret command as shown in the following code sample:

  kubectl create secret generic scancentral-chart-secret \
  --from-file=fortify.license=<FORTIFY_LICENSE_PATH> \
  --from-literal=scancentral-worker-auth-token=<WORKER_AUTH_TOKEN> \
  --from-literal=scancentral-client-auth-token=<CLIENT_AUTH_TOKEN> \
  --from-literal=scancentral-ssc-scancentral-ctrl-secret=<SSC_SECRET>

Creating certificates and required Kubernetes secrets

ScanCentral SAST only works over HTTPS and you must provide valid certificate stores. The following instructions use default secret names from values.yaml, which you can rename if necessary. Make sure the following conditions are met:

1. The Controller requires a keystore that is mounted using Kubernetes secrets which contain a server certificate.
2. Sensors require a truststore that is mounted using Kubernetes secrets to validate the Controller certificate
3. The Controller requires a truststore that is mounted using Kubernetes secrets to validate the Fortify Software Security Center certificate.

Generating a keystore and truststore with a self-signed CA

Note: If you already have a keystore and trustore provided by your organization, ignore this section.

Generate CA trustore and keys:

openssl genpkey -algorithm RSA -out ca.key -pkeyopt rsa_keygen_bits:4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt -subj "/C=MyCountry/ST=MyState/L=MyCity/O=MyCompany/CN=mycompany.com"

Ensure that the country code is a valid two-letter ISO 3166-1 alpha-2 code. For example, US for the United States, GB for the United Kingdom, etc.

Generate a private key for the Controller:

openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

Create a Certificate Signing Request (CSR):

openssl req -new -key server.key -out server.csr -subj "/C=MyCountry/ST=MyState/L=MyCity/O=MyCompany/OU=MyDepartment/CN=sast-25-2-scancentral-sast-controller"

The 'sast-25-2' prefix in the CN is a service name in Kubernetes used to install the Helm chart. If you use a different name, the resolved name in Kubernetes will be different. The value template is: <service-name>-scancentral-sast-controller Ensure that the country code is a valid two-letter ISO 3166-1 alpha-2 code. For example, US for the United States, GB for the United Kingdom, etc. If additional DNS names are required, create a server.ext file. For example:

tee server.ext > /dev/null <<EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = sast-25-2-scancentral-sast-controller.default.svc.cluster.local
DNS.2 = sast-25-2-scancentral-sast-controller
IP.1 = 127.0.0.1
EOF

The 'sast-25-2' prefix in the DNS is a service name in Kubernetes used to install the Helm chart. If you use a different name, the resolved name in Kubernetes will be different. The value template is <service-name>-scancentral-sast-controller.default.svc.cluster.local.

Sign the server certificate with the CA:

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256 -extfile server.ext

Convert the server certificate into a Java keystore, which is used by the Controller:

openssl pkcs12 -export -in server.crt -inkey server.key -CAfile ca.crt -chain -out keystore.p12 -name ctrlKey -password pass:123456
keytool -importkeystore -srckeystore keystore.p12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS -srcstorepass 123456 -deststorepass 123456

Generate a truststore with the CA, which is used by sensors for the connection to the Controller:

keytool -import -trustcacerts -file ca.crt -alias sastCA -keystore truststore.jks -storepass 123456

Creating secrets for the helm chart.

In the examples below, keystore.jks is a keystore used by the Controller, truststore.jks is a truststore to validate both the Controller and Fortify Software Security Center certificates.

Create secrets for the Controller:

kubectl create secret generic sc-sast-server-certificate-keystore --from-file=keystore=keystore.jks
kubectl create secret generic sc-sast-server-certificate-keystore-password --from-literal=password=123456

kubectl create secret generic sc-sast-server-certificate-key-password --from-literal=password=123456
kubectl create secret generic sc-sast-server-certificate-key-alias --from-literal=alias=ctrlKey

kubectl create secret generic sc-sast-server-truststore --from-file=truststore=truststore.jks
kubectl create secret generic sc-sast-server-truststore-password --from-literal=password=123456

Create secrets for sensors:

kubectl create secret generic sc-sast-sensor-truststore --from-file=truststore=truststore.jks
kubectl create secret generic sc-sast-sensor-truststore-password --from-literal=password=123456

Installing ScanCentral SAST components

The following command installs the Controller and sensor (on linux by default) using the recommended defaults. In some cases, you might need to customize these values using the '--set' parameter or by creating a 'values.yaml' and passing it to the command line with '-f' flag. For more information about the values you can override, see the Helm Chart Values table.

Tip: To find the available Fortify ScanCentral SAST 25.2 Helm chart versions, go to https://hub.docker.com/r/fortifydocker/helm-scancentral-sast/tags.

1. Use the following Helm commands to perform the installation:

   Note: The trustedCertificates property is deprecated. OpenText recommends that you provide trusted certificates as follows:

   • For the Controller, mount a truststore using --set controller.truststoreSecret (no needed as long as default secret name and key are used)
   • For sensors, mount a truststore using --set workers.<name>.truststoreSecret (no needed as long as default secret name and key are used)

   helm install <release-name> oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast --version <sc-sast-helm-chart-version> \
     --set secrets.secretName=scancentral-chart-secret \
     --set controller.sscUrl="https://<ssc-svc-name>.<namespace>.svc.cluster.local/ssc"

2. Verify that your ScanCentral SAST pods are running successfully. It might take a few minutes before your pod gets to a proper 1/1 Running state. You can run the following command multiple times or use the flag -w to watch for any changes.

   kubectl get pods

Verifying that the ScanCentral SAST API is available

1. Open a new terminal shell.

2. To access your ScanCentral SAST endpoint, set up port forwarding through kubectl.

   For example, to forward the ScanCentral SAST service on localhost port 8443:

   kubectl port-forward svc/<sc-sast-service-name> 8443:443

   You can determine the <sc-sast-service-name> by using the following command to list the Kubernetes services:

   kubectl get services

3. Verify that you can access the ScanCentral SAST API endpoint with your browser.

   https://localhost:8443/scancentral-ctrl/
   

Integrating ScanCentral SAST with Fortify Software Security Center

Configure your ScanCentral SAST Service URL in Fortify Software Security Center by performing following the steps:

1. Access the Fortify Software Security Center webpage by opening up a new terminal shell and setting up port forward on the Software Security Center service through kubectl. For example, to forward the Software Security Center service on localhost port 8081:

   kubectl port-forward svc/<ssc-service-name> 8081:443

   You can determine the <ssc-service-name> by using the following command to list the Kubernetes services:

   kubectl get services

2. Access the Software Security Center web application from your browser.

   https://localhost:8081

3. After you login to Software Security Center, select the Administration view.

4. Expand Configuration, and then select ScanCentral SAST.

5. Specify the ScanCentral SAST Controller URL, and the SSC and ScanCentral Controller shared secret. Follow the below steps to get the secret.

   kubectl get secret <scancentral-sast-secret-name> -o jsonpath="{.data.scancentral-ssc-scancentral-ctrl-secret}" | base64 -d

   You can determine the 'scancentral-sast-secret-name' by using the following command to list the Kubernetes secrets:

   kubectl get secrets

6. Restart the Software Security Center pod (managed by statefulset) to effect the change by running the following command:

   kubectl rollout restart statefulset <ssc-statefulset-name>

   You can determine the 'ssc-statefulset-name' by using the following command to list the Kubernetes statefulsets:

   kubectl get statefulsets

7. Restarting the Software Security Center statefulset causes its service port forwarding to be interrupted. See step 1 to configure port forwarding again.

8. Login back to Software Security Center. You should see ScanCentral view on the header and you can access the SAST page from that view.

9. See the Software Security Center and ScanCentral SAST documentation to submit a scan requests.

Special Considerations for testing environments:

By default, the Helm chart defines the container resource/requests based on recommended best-practice values intended to prevent performance issues and unexpected Kubernetes evictions of containers and pods. These values are often too large for a small test environment that does not require the same level of resources.

To disable these settings, paste the below values into a file called "resource_override.yaml" and add it to the install commandline with the -f flag. (e.g. -f resource_override.yaml")

WARNING: Using the following settings in production is not supported and will lead to unstable behaviors.

controller:
  resources:
    requests:
      cpu: null
      memory: null
    limits:
      cpu: null
      memory: null
workers:
  linux:
    resources:
      requests:
        cpu: null
        memory: null
      limits:
        cpu: null
        memory: null

Upgrading

• Upgrade notes
• Preparing for the upgrade
• Performing the upgrade
• Verifying that the ScanCentral SAST API is available

Upgrade notes

The current release of the ScanCentral SAST helm chart requires some additional steps in order to run the chart. In addition, the workers section was modified to add the new default windows sensors, which are disabled by default: windows2022 and windows2019.

Preparing for the upgrade

Follow the steps from Installation: Creating certificates and required Kubernetes secrets

Performing the upgrade

1. Create a new values file if neccessary (for example new-values.yaml).

2. Identify the previous ScanCentral SAST release deployment. Use the following command to find it.

   helm list

3. After you identify the previous ScanCentral SAST release, upgrade the Helm chart. Omit the -f new-values.yaml if not needed.

   helm upgrade <release-name> oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast --version <sc-sast-helm-chart-version> \
    --set-file secrets.fortifyLicense=<fortify.license> \
    --set controller.sscUrl="https://<ssc-svc-name>.<namespace>.svc.cluster.local/ssc" \
    -f new-values.yaml

4. Verify that your ScanCentral SAST pods are running successfully. It might take a few minutes before your pod gets to a proper 1/1 Running state. You can run the following command multiple times or use the flag -w to watch for any changes.

   kubectl get pods

Verifying the ScanCentral SAST API is available

Follow the steps from Installation: Verifying the ScanCentral SAST API is available

Troubleshooting

If you encounter issues with the helm upgrade command while using the default Persistent Volume Claim (PVC) instead of providing the controller.persistence.existingClaim value, you might see an error like this:

Error: UPGRADE FAILED: cannot patch "data-sast-25-2-scancentral-sast-controller" with kind PersistentVolumeClaim: PersistentVolumeClaim "data-sast-25-2-scancentral-sast-controller" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests and volumeAttributesClassName for bound claims
  core.PersistentVolumeClaimSpec{
    ... // 2 identical fields
    Resources:        {Requests: {s"storage": {i: {...}, s: "10Gi", Format: "BinarySI"}}},
    VolumeName:       "pvc-ccd73628-6d62-4189-9bff-1786c61b0d46",
-   StorageClassName: &"standard",
+   StorageClassName: nil,
    VolumeMode:       &"Filesystem",
    DataSource:       nil,
    ... // 2 identical fields
  }

To fix this issue, you need to specify a value for controller.persistence.storageClass. First, identify the storage class for your PVC by running:

kubectl get pvc

Look for the STORAGECLASS value associated with the PVC created for the Controller. Then, you can either explicitly specify this storage class name in your custom values.yaml file:

controller:
  persistence:
    storageClass: "<class_name>"

Alternatively, you can set it using the helm upgrade command:

helm upgrade --set controller.persistence.storageClass="<class_name>" --reuse-values <release_name>

Values

The following values are exposed by the Helm chart. Unless specified as Required, values should only be overridden as made necessary by your specific environment.

Required

Other Values