Skip to main content

Licensing Procedure for Kubernetes/OpenShift for Security Server 3.4.*

Security Server 3.4.* and later

  1. Adjust helm values.

  2. Set helm chart parameter testInstallation to false

  3. Set the helm chart parameter caKeyStorePassphrase to your desired CA passphrase (also ensure to configure parameter countryCode, organization and email under section ssms:certificate for the used "values.yaml")

  4. In case of "Migration install" - using the existing Security Server-database for new deployed services hosted on Kubernetes the license procedure is not required. Create the "ssms-local-config" secret and adopt the "caKeyStorePassphrase" as appropriate as this allows the Security Server-service accessing the Security Server-DB-data covering the existing license (more info here Migration install)

  5. Helm install Security Server (as part of the mPower deployment)

  6. Monitor the job pod named "<release>-ssms-master-config". The logs will indicate that the Certificate Sign Request (CSR) has been generated. It is normal for the job to fail after this step. The helm deployment can be uninstalled at this stage to avoid a restart loop, but this is not necessary.

  7. Acquire the CSR from the secret called "ssms-certificate-sign-request" from the namespace where Security Server was installed (obsolete for 1.c "Migration install")

  8. An example command for kubernetes is:

       kubectl get secret -n <namespace> ssms-certificate-sign-request -o jsonpath='{.data.ssms-csr.p10}' | base64 --decode > ssms-dev-csr.p10    
  9. Acquire an Security Server license from KOBIL with the CSR as per above command (send "ssms-dev-csr.p10" to Kobil Support or Project Team)

  10. Import the license into a secret named "ssms-license" in the namespace where Security Server should be installed

  11. An example command for kubernetes is (note that the filename must be license.zip):

       kubectl create secret generic -n ssms ssms-license --from-file=license.zip  
  12. Run again helm install or a helm upgrade.

Monitor the new "ssms-master-config" pod. It should log that the license was applied. Due to delay for getting the "license.zip" file the initial "helm install" processing might terminated leaving the "RELEASE" deployment in status "failed". This may cause "helm upgrade" to fail as there is no valid RELEASE deployment. In this case run a "helm uninstall" and re-running the "helm install" using the very same Cluster and Namespace which was used to creating the CSR secret. The "helm uninstall" will remove the "ssms-certificate-sign-request", but having the created "ssms-license" secret still valid. At this time the "helm install" will run fine and completes the registered Security Server-setup.

Verification for successful load of "ssms-license" k8s secret is by logged line in the "ssms-master-config" pod log covering:

"Trying to get the certificate and license zip from k8s secret." and "Certificate and license zip file was processed. New license installed."