Deploying ScanCentral SAST in Kubernetes

This document describes how to configure and use the scancentral-sast 25.4 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.32
• Kubernetes 1.33
• Kubernetes 1.34

Helm version

• Helm 3.18
• Helm 3.19

Tool prerequisites

• kubectl v1.34.x
• helm v3.19.x
• Java keytool utility

OpenText recommends running Fortify on the tested platforms described in the product system requirements documentation. However, customers running on other platforms or with untested configurations will be supported until the point OpenText determines that the root cause is the untested platform or configuration. Issues that can be reproduced on the tested platforms will be prioritized and fixed according to standard defect-handling policies.

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.4 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. Configuring sensitive ScanCentral SAST properties
4. Configuring ScanCentral SAST Controller properties
5. Installing ScanCentral SAST components
6. Verifying that the ScanCentral SAST API is available
7. Integrating ScanCentral SAST with Fortify Software Security Center
8. 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=https://index.docker.io/v1/ \
   --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

Configuring sensitive ScanCentral SAST properties

If any of the following sensitive properties need to be provided to the ScanCentral SAST Controller, they should be configured as Kubernetes secrets. If none of these properties need to be configured, skip to the next section.

Application Security Controller service account

Configuration file: config.properties

ssc_ctrl_account_username=
ssc_ctrl_account_password=

Create Kubernetes secret:

kubectl create secret generic sc-sast-ssc-svc-account-secret --from-literal=username=svc_username --from-literal=password=svc_password

The helm install should include the --set controller.sscSvcAccount.enabled=true option. Refer to the values table to override default secret and key names if necessary.

Swagger documentation page credentials

Configuration file: config.properties

swagger_username=
swagger_password=

Create Kubernetes secret:

kubectl create secret generic sc-sast-swagger-secret --from-literal=username=swagger_username --from-literal=password=swagger_password

The helm install should include the --set controller.swagger.enabled=true option. Refer to the values table to override default secret and key names if necessary.

LIM credentials

Configuration file: config.properties

lim_license_pool_password=
lim_proxy_user=
lim_proxy_password=

Create Kubernetes secret:

kubectl create secret generic sc-sast-lim-secret --from-literal=pool-password=password --from-literal=proxy-user=username --from-literal=proxy-password=password

The helm install should include the --set controller.lim.enabled=true --set.controller.lim.proxy.enabled=true option. Refer to the values table to override default secret and key names if necessary.

SMTP server credentials

Configuration file: config.properties

smtp_auth_user=
smtp_auth_pass=

Create Kubernetes secret:

kubectl create secret generic sc-sast-smtp-secret --from-literal=username=username --from-literal=password=password

The helm install should include the --set controller.smtp.enabled=true option. Refer to the values table to override default secret and key names if necessary.

Configuring ScanCentral SAST Controller properties

ScanCentral SAST Controller properties are defined in the config.properties file. To configure these properties, you can use the controller.additionalEnvironment value in the Helm chart.

To set up ScanCentral SAST Controller properties, use environment variables prefixed with SCANCENTRAL_CONFIG_. The string following the prefix is the property name in uppercase. The container entrypoint will handle the conversion of the property name. For example:

To set the include_job_status_in_email_subject property to false, use the following environment variable:

SCANCENTRAL_CONFIG_INCLUDE_JOB_STATUS_IN_EMAIL_SUBJECT=false

The helm install should include the

  --set controller.additionalEnvironment[0].name=SCANCENTRAL_CONFIG_INCLUDE_JOB_STATUS_IN_EMAIL_SUBJECT \
  --set controller.additionalEnvironment[0].value=false

Refer to the ScanCentral SAST documentation to get information about the available properties.

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.4 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 imagePullSecrets[0].name=docker.io
     --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 imagePullSecrets[0].name=docker.io
    --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 <release_name> --set controller.persistence.storageClass="<class_name>" --reuse-values

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