Deploying Fortify Software Security Center in Kubernetes

This document describes how to configure and use the helm-ssc Helm chart for complete Software Security Center container orchestration in Kubernetes. You can find the Software Security Center Helm chart at https://hub.docker.com/r/fortifydocker/helm-ssc.

Table of contents

• Kubernetes Versions
• Tool Prerequisites
• Installation
• Upgrade

Kubernetes versions

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.

These charts have been tested using the following Kubernetes versions:

• Kubernetes 1.34
• Kubernetes 1.35

Tool prerequisites

• kubectl v1.34.x
• helm v3.19.x
• Java keytool utility
• yq command line tool for parsing YAML files. See the yq GitHub repository for installation instructions.

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

• For details on installing versions of these tools, see the official documentation

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 some commands and other Kubernetes Cluster providers might require additional/different configurations. Your Kubernetes administrator might require the use of specific namespaces and/or other configuration adjustments.

Installation prerequisites

• A working Kubernetes cluster
• A Kubernetes Storage Class to use for Software Security Center persistence.
• A supported database for Software Security Center system requirements.

Installation steps

1. Preparing the Fortify license file
2. Preparing HTTP certificate passwords
3. Preparing the HTTP keystore file
4. Preparing the Software Security Center autoconfig file
5. Preparing the Software Security Center Kubernetes secrets
6. Creating an image pull secret
7. Installing the Software Security Center release
8. Setting up port forwarding through kubectl
9. Verifying that Software Security Center is available
10. Testing the admin login
11. Special considerations for testing environments

Preparing the Fortify license file

• Obtain the Fortify license and store it in the /tmp folder as fortify-license.txt so that it can be accessed as /tmp/fortify-license.txt.

Preparing HTTP certificate passwords

• Run the following commands to create separate passwords for the keystore and certificate key:

  HTTP_KEYSTORE_PWD="$(openssl rand -base64 32)"
  HTTP_KEY_PWD="$(openssl rand -base64 32)"

  Important: Keep these environment variables set for the next steps. Do not close your terminal or run unset until all secrets are created.

Preparing the HTTP keystore file

• Run the following command to create the HTTP keystore file using the passwords from the previous step:

  keytool -genkeypair -keyalg RSA -keysize 2048 -keystore /tmp/httpKeystore.jks -storetype JKS -alias ssc-server -storepass "$HTTP_KEYSTORE_PWD" -keypass "$HTTP_KEY_PWD" -dname "CN=CA, OU=IT, O=OpenText, L=Waterloo, ST=Ontario, C=CN"

  Note: We explicitly specify -storetype JKS to create a JKS keystore, which supports different passwords for the keystore and the private key. Modern Java defaults to PKCS12 format which requires the same password for both.

  Verify the keystore was created correctly:

  # This command should succeed without errors if the passwords are correct
  keytool -list -keystore /tmp/httpKeystore.jks -storetype JKS -storepass "$HTTP_KEYSTORE_PWD" -alias ssc-server

Preparing the Software Security Center autoconfig file

1. Create a file /tmp/ssc.autoconfig.tpl and copy the following content to it.

   appProperties:
     host.validation: false
     authentication.max.concurrent.logins: 1
   
   datasourceProperties:
     db.username: '<DB-USERNAME>'
     db.password: '<DB-PASSWORD>'
   
     jdbc.url: 'jdbc:sqlserver://<DB-HOST>;database=<DB-NAME>;sendStringParametersAsUnicode=false;trustServerCertificate=true'
   
   dbMigrationProperties:
     migration.enabled: true
     migration.username: '<DB-USERNAME>'
     migration.password: '<DB-PASSWORD>'

• This is an example autoconfig file for a MS SQL Server database. You might have to modify this based on your database. Update the values of <DB-USERNAME>, <DB-PASSWORD>, <DB-HOST> and <DB-NAME> for your environment.

Preparing the Software Security Center Kubernetes secrets

Create separate secrets for each configuration item:

1. Create the license secret:

   kubectl create secret generic ssc-license \
     --from-file=sscLicense=/tmp/fortify-license.txt

2. Create the autoconfig secret:

   kubectl create secret generic ssc-autoconfig \
     --from-file=sscAutoconfig=/tmp/ssc.autoconfig.tpl

3. Create the HTTP certificate keystore secret:

   kubectl create secret generic ssc-http-keystore \
     --from-file=httpCertificateKeystore=/tmp/httpKeystore.jks

4. Create the HTTP certificate passwords secrets:

   kubectl create secret generic ssc-http-keystore-password \
     --from-literal=httpCertificateKeystorePassword="$HTTP_KEYSTORE_PWD"
     
   kubectl create secret generic ssc-http-key-password \
     --from-literal=httpCertificateKeyPassword="$HTTP_KEY_PWD"

5. Clean up temporary files:

   rm /tmp/httpKeystore.jks /tmp/ssc.autoconfig.tpl /tmp/fortify-license.txt
   unset HTTP_KEYSTORE_PWD HTTP_KEY_PWD

6. Optional: For SAML configuration, if you need SAML authentication, create an IDP certificate secret:

   kubectl create secret generic ssc-idp-certificate \
      --from-file=idpCertificate=/path/to/idp-certificate.crt

Creating an image pull secret

By default, the Software Security Center 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 example code:

  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>'

Installing the Software Security Center release

The following command installs the Software Security Center using the recommended defaults. In some cases, you might need to customize these values using the Helm --set parameter or by creating a values.yaml override file and passing it to the command line with the Helm -f flag. For more information about the values you can override, see the Helm Chart Values table.

Tip: To find the available Software Security Center Helm chart version, go to https://hub.docker.com/r/fortifydocker/helm-ssc/tags.

• Use the following command to install Software Security Center.

  helm install <release-name> oci://registry-1.docker.io/fortifydocker/helm-ssc --version <ssc-helm-chart-version> \
   --set imagePullSecrets[0].name=docker.io \
   --set sscLicenseSecret=ssc-license \
   --set sscLicenseKey=sscLicense \
   --set httpCertificateKeystoreSecret=ssc-http-keystore \
   --set httpCertificateKeystoreKey=httpCertificateKeystore \
   --set httpCertificateKeystorePasswordSecret=ssc-http-keystore-password \
   --set httpCertificateKeystorePasswordKey=httpCertificateKeystorePassword \
   --set httpCertificateKeyPasswordSecret=ssc-http-key-password \
   --set httpCertificateKeyPasswordKey=httpCertificateKeyPassword \
   --set urlHost=<preferred-ssc-url-hostname>

Setting up port forwarding through kubectl

1. Verify that your Software Security Center pod (ssc-webapp-0) is running successfully. It might take a few minutes before your pod gets to a proper 1/1 Running configuration. You can run the command above multiple times or use the flag -w to watch for any changes.

   kubectl get pods

2. Open a new terminal shell.

3. Set up port forwarding through kubectl to access your Software Security Center endpoint.

   For example, to forward the localhost port 8081:

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

   ssc-service-name can be determined by listing the Kubernetes services using the following command:

   kubectl get services

Verifying that Software Security Center is available

1. Follow the steps in Setting up port forwarding through kubectl.

2. You should now be able to access the Software Security Center web endpoint from your browser.

   https://localhost:8081

Testing the admin login

1. Follow the steps in Setting up port forwarding through kubectl.

2. Access the login endpoint from your browser:

   https://localhost:8081

3. Log in to Software Security Center with the default admin credentials. The default username is admin and the password is admin. You must change the admin password the first time you login.

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. You can override the resource requests by passing additional value --set resources=null in the helm install command above.

WARNING: Using the above option in production is not supported and will lead to unstable behavior.

Upgrade

This section explains how to upgrade Software Security Center from a previous release to version 26.2.

Upgrade prerequisites

• A running Software Security Center deployment
• Helm CLI access to your Software Security Center environment
• kubectl access to the Kubernetes cluster

Upgrading from previous version

Important: Version 25.4 introduced a breaking change in secret management architecture. If you are upgrading from a previous version, you must migrate from the monolithic secret approach to discrete secrets before proceeding with the upgrade.

Important: Refer to SSC User Guide for Upgrade of SSC from 25.4 to 26.2 for the support of MYSQL8.4

Upgrade steps

1. Migrating from monolithic secret to discrete secrets
2. Preparing the values file
3. Upgrading the Software Security Center release
4. Verifying Software Security Center after the upgrade

Migrating from monolithic secret to discrete secrets

Version 25.4 replaced the single monolithic secret architecture with discrete secrets. This new approach provides: If you are upgrading from a previous version that used the secretRef configuration with a single secret (typically named ssc-secret), follow these migration steps.

1. Export the important environment variables for secrets migration.

   export SSC_HELM_RELEASE=<SSC_HELM_RELEASE>   # Replace with your SSC release name
   export SSC_NAMESPACE=<SSC_NAMESPACE>  # Replace with the namespace in which SSC is deployed
   export SSC_SECRET_NAME=$(helm -n $SSC_NAMESPACE get values $SSC_HELM_RELEASE  | yq .secretRef.name)

2. Create the ssc-license secret from the existing secret

   SSC_LICENSE_KEY=$(helm -n $SSC_NAMESPACE get values $SSC_HELM_RELEASE | yq -r '.secretRef.keys.sscLicenseEntry')
   kubectl -n $SSC_NAMESPACE get secret $SSC_SECRET_NAME -o yaml | yq eval -r ".data[\"$SSC_LICENSE_KEY\"]" | base64 -d > /tmp/fortify-license.txt
   kubectl -n $SSC_NAMESPACE create secret generic ssc-license --from-file=sscLicense=/tmp/fortify-license.txt

3. Create the ssc-autoconfig secret from the existing secret

   SSC_AUTOCONFIG_KEY=$(helm -n $SSC_NAMESPACE get values $SSC_HELM_RELEASE  | yq -r '.secretRef.keys.sscAutoconfigEntry')
   kubectl -n $SSC_NAMESPACE get secret $SSC_SECRET_NAME -o yaml | yq eval -r ".data[\"$SSC_AUTOCONFIG_KEY\"]" | base64 -d > /tmp/ssc-autoconfig.tpl
   kubectl -n $SSC_NAMESPACE create secret generic ssc-autoconfig --from-file=sscAutoconfig=/tmp/ssc-autoconfig.tpl

4. Create the ssc-http-keystore secret from the existing secret

   HTTP_KEYSTORE_FILE_KEY=$(helm -n $SSC_NAMESPACE get values $SSC_HELM_RELEASE  | yq -r '.secretRef.keys.httpCertificateKeystoreFileEntry')
   kubectl -n $SSC_NAMESPACE get secret $SSC_SECRET_NAME -o yaml | yq eval -r ".data[\"$HTTP_KEYSTORE_FILE_KEY\"]" | base64 -d > /tmp/httpKeystore.jks
   kubectl -n $SSC_NAMESPACE create secret generic ssc-http-keystore --from-file=httpCertificateKeystore=/tmp/httpKeystore.jks

5. Create the ssc-http-keystore-password secret from the existing secret

   HTTP_KEYSTORE_PWD_KEY=$(helm -n $SSC_NAMESPACE get values $SSC_HELM_RELEASE  | yq -r '.secretRef.keys.httpCertificateKeystorePasswordEntry')
   HTTP_KEYSTORE_PWD=$(kubectl -n $SSC_NAMESPACE get secret $SSC_SECRET_NAME -o yaml | yq eval -r ".data[\"$HTTP_KEYSTORE_PWD_KEY\"]" | base64 -d)
   kubectl -n $SSC_NAMESPACE create secret generic ssc-http-keystore-password --from-literal=httpCertificateKeystorePassword="$HTTP_KEYSTORE_PWD"

6. Create the ssc-http-key-password secret from the existing secret

   HTTP_KEY_PWD_KEY=$(helm -n $SSC_NAMESPACE get values $SSC_HELM_RELEASE  | yq -r '.secretRef.keys.httpCertificateKeyPasswordEntry')
   HTTP_KEY_PWD=$(kubectl -n $SSC_NAMESPACE get secret $SSC_SECRET_NAME -o yaml | yq eval -r ".data[\"$HTTP_KEY_PWD_KEY\"]" | base64 -d)
   kubectl -n $SSC_NAMESPACE create secret generic ssc-http-key-password --from-literal=httpCertificateKeyPassword="$HTTP_KEY_PWD"

7. If present, optionally migrate additional secret keys such as the HTTP truststore, JVM truststore, SAML IDP certificate, etc. For each key, execute the corresponding command and replace all placeholder values with the appropriate configuration details.

   SECRET_KEY_ENTRY_NAME="<PLACEHOLDER_OLD_SECRET_KEY_NAME>"  # e.g., sscSecretKeyEntry, idpCertificateEntry, httpTruststoreFileEntry
   NEW_SECRET_NAME="<PLACEHOLDER_NEW_SECRET_NAME>"             # e.g., ssc-secret-key, idp-certificate, http-truststore
   NEW_SECRET_KEY="<PLACEHOLDER_NEW_SECRET_KEY>"               # e.g., sscSecretKey, idpCertificate, httpTruststore
   TEMP_FILE_PATH="<PLACEHOLDER_TEMP_FILE_PATH>"               # e.g., /tmp/secret.txt, /tmp/cert.pem
   
   # Extract and migrate the secret
   SECRET_VALUE=$(helm -n $SSC_NAMESPACE get values $SSC_HELM_RELEASE | yq -r ".secretRef.keys.$SECRET_KEY_ENTRY_NAME")
   kubectl -n $SSC_NAMESPACE get secret $SSC_SECRET_NAME -o yaml | yq eval -r ".data[\"$SECRET_VALUE\"]" | base64 -d > "$TEMP_FILE_PATH"
   kubectl -n $SSC_NAMESPACE create secret generic "$NEW_SECRET_NAME" --from-file="$NEW_SECRET_KEY=$TEMP_FILE_PATH"
   rm -f "$TEMP_FILE_PATH"

8. Remove temporary files and clear environment variables to maintain security:

   # Remove all temporary files
   rm -f /tmp/fortify-license.txt /tmp/ssc-autoconfig.tpl /tmp/httpKeystore.jks
   rm -f /tmp/httpTruststore.jks /tmp/jvmTruststore.jks /tmp/idpCertificate.crt
   
   # Clear environment variables
   unset HTTP_KEYSTORE_PWD HTTP_KEY_PWD HTTP_TRUSTSTORE_PWD JVM_TRUSTSTORE_PWD EXISTING_SECRET_NAME

Preparing the values file

Update your values.yaml file to reference the new discrete secrets instead of the monolithic secret structure.

Previous configuration (monolithic secret):

secretRef:
  name: ssc-secret
keys:
  sscLicenseEntry: fortify-license.txt
  sscAutoconfigEntry: ssc.autoconfig.tpl
  httpCertificateKeystoreFileEntry: httpKeystore.jks
  httpCertificateKeyPasswordEntry: httpCertificateKeyPassword
  httpCertificateKeystorePasswordEntry: httpCertificateKeystorePassword

New configuration (discrete secrets):

# Required secrets - these must be configured
sscLicenseSecret: ssc-license
sscLicenseKey: sscLicense
httpCertificateKeystoreSecret: ssc-http-keystore
httpCertificateKeystoreKey: httpCertificateKeystore
httpCertificateKeystorePasswordSecret: ssc-http-keystore-password
httpCertificateKeystorePasswordKey: httpCertificateKeystorePassword
httpCertificateKeyPasswordSecret: ssc-http-key-password
httpCertificateKeyPasswordKey: httpCertificateKeyPassword

# Optional secrets - uncomment and configure if you have these configuration in your environment
# sscAutoconfigSecret: ssc-autoconfig
# sscAutoconfigKey: sscAutoconfig
# sscSecretKeySecret: ssc-secret-key
# sscSecretKeyKey: sscSecretKey
# httpTruststoreSecret: ssc-http-truststore
# httpTruststoreKey: httpTruststore
# httpTruststorePasswordSecret: ssc-http-truststore-password
# httpTruststorePasswordKey: httpTruststorePassword
# jvmTruststoreSecret: ssc-jvm-truststore
# jvmTruststoreKey: jvmTruststore
# jvmTruststorePasswordSecret: ssc-jvm-truststore-password
# jvmTruststorePasswordKey: jvmTruststorePassword
# idpCertificateSecret: ssc-idp-certificate
# idpCertificateKey: idpCertificate

Note: The sscAutoconfigSecret and sscAutoconfigKey parameters are optional. When omitted (or left as empty strings), SSC will start in manual installation wizard mode, allowing you to configure the database and other settings through the web interface.

After updating the secret references, review and merge any other configuration changes from the current release. See the complete values reference for all available configuration options.

Upgrading the Software Security Center release

Execute the Helm upgrade command to apply the new configuration:

helm -n $SSC_NAMESPACE upgrade $SSC_HELM_RELEASE oci://registry-1.docker.io/fortifydocker/helm-ssc \
  --version <ssc-helm-chart-version> \
  -f values.yaml \
  --reuse-values

Replace:

• <ssc-helm-chart-version> with the target version (e.g., 26.2.0)

Verifying Software Security Center after the upgrade

After completing the upgrade, verify that Software Security Center is functioning correctly:

1. Check that the pod is running:

   kubectl -n $SSC_NAMESPACE get pods -l app.kubernetes.io/name=ssc

2. Verify Software Security Center is accessible by following the steps in Setting up port forwarding through kubectl and confirming you can access the web interface at https://localhost:8081.

3. Test the admin login following the steps in Testing the admin login.

4. Verify your existing applications and scan results are intact.

Post-upgrade cleanup (optional)

After thoroughly testing the upgraded deployment and confirming everything works correctly, you can safely remove the old monolithic secret:

# Only execute this command after verifying the upgrade was successful
kubectl -n $SSC_NAMESPACE delete secret $SSC_SECRET_NAME

Warning: Do not delete the old secret until you have verified that:

• The SSC pod is running successfully
• You can log in and access the application
• All functionality is working as expected

Note: Ensure to temporarily retain the old secret in case you want to rollback the deployment.

Values

The following values are exposed by the Helm Chart. Unless specified as Required, only override values as required for your specific environment.

Required

Other Values