Skip to main content

Security Server-ST Database migration into Subtenant

Moving Security Server SingleTenant (R2.**) data into a Security Server MultiTenant (R3.5++) subtenant context is done by "installer db-miration" script. This will then result in a Security Server Master-Tenant for administrative access and an additional Sub-Tenant covering all customer user, device and version data from the Security Server R2 database. The DB-migration for single-tenant Security Server-DB data into a subtenant is possible only by "installer Security Server 3.5*/3.6*" install. Starting a k8s-Security Server service by new k8s install will do auto-migration of Single-Tenant Data into MASTER Tenant.

Running DB-Migration into Multi-Tenant Security Server DB context - overview​

  • make use of existing installer Security Server R 2.* host and upgrade to installer Security Server R 3.*
  • check by starting CU to have access to the configured Security Server-DB services
  • run the db-migration script (per default or with specific Kobil custom scripts / see below)
  • do not run the CU at installer Security Server - nor deploy modules.
  • run helm install mpower -f ./values.yaml kobil/mpower
  • Security Server DB data completion is processed automatically by Kobil Security Server Pods/Jobs (watch "ssms-master-config*" Pod log output )
  • watch "ssms-mgt/svc" Pod log output to verify access and reading from Security Server-DB is possible matching the Security Server-modules to Security Server-table versions

Installer Security Server 3.5*/3.6* howto​

This would require to install (new) Security Server-installer version native at OS-level overruling existing Security Server 2* installation - or using new Security Server 3* host with appropriate configuration to access Security Server 2.* DB-services (using the config.xml file).
When installation (or upgrade) to install SSSM r 3.* is done configure/check by CU to have proper DB-access (using from original Security Server-install the config.xml to enable correct Security Server-DB access will do) but do no further processing and actions by the CU runtime (do not apply modules or certificate). Just verify the CU Security Server-DB access check.

Ensure to make use of Installer-Security Server Release matching to the targeted k8s-Security Server-release which is used later on for the kubernetes deployment. Do not mixup like installer Security Server R 3.5.2 with Kubernetes Security Server R 3.6.1.

In case your install is a custom Security Server at installer Security Server R 2.* level please check with Kobil services to verify if specific db-migration script adoptions are required. Those specific script will be provided by Kobil and are copied into the ./tool/db-migration path prior to run the "db-migration".

Now running the DB-migration (make use of Installer-Security Server Release which is matching to the targeted k8s-Security Server-release / with then matching mPower & Security Server-chart package version appropriate to the Security Server-image/release).
During runtime of the DB-migration tool, the dialog is asking for a "Tenantname" - update this with the new tenant-name and this will complete "MT-subtenant" db-migration. The "Tenantname" is processed to uppercase characters for the Security Server Tenant Name.

Accessing migrated Security Server-DB data by k8s-deployment​

  • initial deployment is start a "master-config" job/pod checking for valid Security Server-DB access
  • embedded CU startup will complete db-migration and also updating "node-names" (doublecheck the caKeyStorePassphrase is correctly set in the meta-configuration file "values.yaml")
  • new MASTER tenant configuration by configured meta-configuration file "values.yaml" parameter (global.ssms.superadmin.username and .password) is automatically done

Follow up:

  • MASTER tenant advanced settings are defaulted.
  • Subtenant advanced settings are only taken from installer Security Server context if those are available at sub-tenant context.
  • Verify "subtenant" data is OK
  • Verify the MASTER to Subtenant hierarchy once MASTER AdvancedSettings is reapplied