Connect to an On-Premises Database Using the Secure Data Service (Container Only)

The following functionality is only available for MCE and MCS container environments.

Strategy (September 2026) adds support to deploy SDS as a container in a Kubernetes and an OpenShift cluster.

Strategy One (March 2026) introduces the Secure Data Service (SDS), a secure connectivity solution that enables Intelligence server instances in Strategy MCE and MCS to access on-premises data warehouse servers while the corresponding database credentials and connection management remain on your premises and under your control. SDS is the next evolution of DGS, preserving its core purpose with a stronger focus on keeping authentication and connectivity for those selected databases entirely within your environment.

Deployed on a machine or container within your on-premises network, SDS uses Strategy Data Gateway technologies to establish secure, on-demand communication channels via a Data Gateway Server, eliminating the need for dedicated private links or VPNs. SDS uses TLS-encrypted channels, initiated by one or more (when clustered) SDS agents in your environment, to send warehouse query results from your network to your Strategy MCE and MCS environments without exposing inbound access or forwarding arbitrary traffic to other internal systems. It relies on Library REST APIs for connection as well as authentication, and supports locally stored RSA-encrypted database credentials and direct retrieval from Vault servers, so sensitive credentials are not stored in Strategy's cloud. SDS consists of two components, SDS Agent and DGS Agent. In the following documentation, the term SDS refers to both the SDS and DGS agent.

Using SDS may cause some performance degradation compared to connecting directly to the warehouse database locally, due to the additional network hop. To mitigate degradation, Strategy suggests using In-Memory Intelligent Cubes. For more information on product constraints and supported configurations, see SDS Limitations and Troubleshooting.

Deploy SDS

Installer in Linux
Container in Linux
Container in Windows
Container in Kubernetes and OpenShift

Prerequisites

Note the Library URL for your MCE or MCS environment.
Ensure Data Gateway Server (DGS) is enabled. To enable DGS, contact your cloud support administrator.
Ensure you have a Red Hat Enterprise Linux 9.x machine with at least 8 vCPUs, 32 GB of RAM, and 20GB of disk free space. The machine must reside in the same private network as the Warehouse database. The machine must also be able to reach the Library REST API server hosted on MCE or MCS, which is typically exposed through a load balancer. Strategy recommends a dedicated machine for SDS.
SDS provides a web UI on ports 8080 (HTTP) and 8443 (HTTPS) on the Linux server. If the server has a desktop environment, open a web browser and access the UI locally. If you want to use a browser from another machine, ensure it can reach the Linux server on ports 8080 or 8443, and update your firewall settings, if needed.
Ports 8080 (HTTP), 8443 (HTTPS), and 55555 must be available and not in use on the Linux machine.

You can also deploy SDS using Docker containers on Linux and Windows.

Install SDS

In Strategy Community, in the Federated Data Connectors category, download the Linux Installer for Secure Data Service (SDS).
Copy the downloaded zip file to the target machine where SDS will be deployed.
SDS must be installed in the /opt directory. Create the directory, if it does not already exist.

Extract the .zip file into /opt:

Copy

sudo mkdir -p /opt
sudo unzip secure-data-service-linux.zip -d /opt
sudo chmod +x /opt/mstr/dgs-sds-service.sh

Register and start SDS as a service by running the following commands:

The command should complete in under one minute.
Copy
```
cd /opt/mstr
sudo ./dgs-sds-service.sh install
sudo ./dgs-sds-service.sh start
```
To check the status of the SDS service (the SDS agent and the DGS agent), run the following command:
Copy
```
sudo ./dgs-sds-service.sh status
```

This starts SDS as a web server listening on ports 8080 (HTTP) and 8443 (HTTPS) by default. These ports expose the web UI used for configuration, as described in the following steps. To customize the ports, edit the following section in /opt/mstr/dgsagent/config/application.properties and restart SDS:

Copy

# HTTPS port
server.port=8443
# HTTP port
server.http.port=8080

sudo ./dgs-sds-service.sh restart

Note that the script also supports stopping and uninstalling SDS using the following commands:

Copy

sudo ./dgs-sds-service.sh stop
sudo ./dgs-sds-service.sh uninstall

Deploy SDS as a Container in Linux

SDS can be deployed as a container on Linux operation systems.

Prerequisites

Before you can deploy SDS as a container on Linux, you must prepare a virtual machine that meets the following criteria:

A dedicated machine for SDS.
At least 8 vCPUS, 32GB of RAM, and 30GB of disk free space.
A Red Hat Enterprise Linux (RHEL) 9.x operating system.
SDS provides a web UI on ports 8080 (HTTP) and 8443 (HTTPS) on the Linux server. If the server has a desktop environment, use a web browser. If you want to use a browser from another machine, ensure it can communicate with the Linux server on ports 8080 or 8443 and update the firewall settings, if needed.
Ports 8080 (HTTP), 8442 (HTTPS), and 55555 must be available and not in use on the Linux machine.
The docker compose command is available. If it is not available, install the Docker Engine using the Docker Documentation. Ensure that you install the Docker Compose v2 CLI plugin (docker compose), and not docker-compose (with a hyphen), which is the legacy v1 standalone binary.

Install SDS as a Container in Linux

In Strategy Community, in the Federated Data Connectors category, download the Container Package for Secure Data Service (SDS).
Copy the downloaded zip file to the target machine where SDS will be deployed.

Extract the .zip file into a target folder, such as /home/admin/secure-data-service:

Copy

mkdir -p /home/admin/secure-data-service
unzip secure-data-service-container.zip -d /home/admin/secure-data-service

Go to the target directory and run the command to set up and start the SDS container:

The command should complete in under one minute.
Copy
```
cd /home/admin/secure-data-service
./dgs-sds-container.sh start
```
This command uses Docker Compose to deploy the container. If the command fails, run it with sudo privileges or complete the Linux post-installation steps for Docker Engine before trying again.
After the SDS container is deployed, run one of the following commands to check the status:

Option 1:
Copy
```
./dgs-sds-container.sh status
```
Option 2:
Copy
```
docker compose ps -a
```
To verify the SDS container is running correctly, open a web browser and go to http://<docker-vm-hostname>:8080/ or https://<docker-vm-hostname>:8443/, where <docker-vm-hostname> is the host name or IP address of the Linux virtual machine. The browser should display similar to the following when the SDS is running correctly:

If you are accessing SDS from a different machine, ensure the SDS host firewall allows inbound connections on port 8080 and/or 8443. This is typically required when the Linux host is accessed remotely.

When accessing the HTTPS endpoint, your browser may display a Your connection is not private warning. To resolve this issue, see Fix the Connection Not Private Web Browser Error.
Optionally, modify the host port numbers by modifying the value before ":" in the relevant ports entries in the docker-compose.yml file. In the following example, the HTTP port updates from 8080 to 8081 and the HTTPS port updates from 8443 to 8444:
Copy
```
    ports:
      - "55555:55555"
      - "26214-26313:26214-26313"
      - "8081:8080"
      - "8444:8443"
```
If you modify the port numbers, restart the SDS using one of the following commands:

Option 1:
Copy
```
./dgs-sds-container.sh restart
```
Option 2:
Copy
```
docker compose up -d
```

SDS can be deployed as a container on Windows. However, because this option requires additional virtualization on the Windows host and may introduce performance overhead, Strategy does not recommend this option, unless deployment on Linux is not possible.

Prerequisites

Before you can deploy SDS as a container on Windows, ensure the following prerequisites:

Strategy recommends a bare-metal (physical) machine. If you are using a virtual machine, it must support nested virtualization. In all cases, SDS should run on a dedicated machine.
A Microsoft Windows 11 or Windows Server 2025 system with a minimum of 8 vCPUS, 32GB of RAM, and 50GB of disk free space.
Ports 8080 (HTTP), 8442 (HTTPS), and 55555 must be available and not in use on the machine.
Docker Desktop or Rancher Desktop is installed on the Windows host. You may also need to install Windows Subsystem for Linux before installing Docker or Rancher Desktop.

Install SDS as a Container in Windows

In Strategy Community, in the Federated Data Connectors category, download the Container Package for Secure Data Service (SDS).
Copy the downloaded zip file to the target machine where SDS will be deployed.
Extract the .zip file into a target folder, such as C:\SDS\ folder.
Go to the PowerShell terminal, navigate to the target folder, and run the command to start the SDS container:

The command should complete in under one minute.
Copy
```
.\dgs-sds-container.ps1 start
```
If a PSSecurityException error occurs, you may need to bypass the execution policy ( for example, by running powershell.exe -ExecutionPolicy Bypass) before re-running the scripts.
After the SDS container is deployed, run one of the following commands to check the status:

Option 1:
Copy
```
.\dgs-sds-container.ps1 status
```
Option 2:
Copy
```
docker compose ps -a
```
To verify the SDS container is running correctly, open a web browser and go to http://<docker-vm-hostname>:8080/ or https://<docker-vm-hostname>:8443/, where <docker-vm-hostname> is the host name or IP address of the Linux Windows machine. The browser should display similar to the following when the SDS is running correctly:

When accessing the HTTPS endpoint, your browser may display a Your connection is not private warning. To resolve this issue, see Fix the Connection Not Private Web Browser Error.
Optionally, modify the host port numbers by modifying the value before ":" in the relevant ports entries in the docker-compose.yml file. In the following example, the HTTP port updates from 8080 to 8081 and the HTTPS port updates from 8443 to 8444:
Copy
```
    ports:
      - "55555:55555"
      - "26214-26313:26214-26313"
      - "8081:8080"
      - "8444:8443"
```
If you modify the port numbers, restart the SDS using the following command:
Copy
```
docker compose up -d
```

Prerequisites

The following software and access is required:
- A supported cluster with Kubernetes 1.23 or later, or Red Hat OpenShift 4.x.
- Helm 3.x installed on the administration workstation. Use the Helm version supported by your organization and target cluster.
- The kubectl (for Kubernetes) or oc (for OpenShift) command configured with credentials that can create resources in the target namespace.
- Permissions to create and manage the following Kubernetes/OpenShift resources, aligned with your organization policy: StatefulSets, Services, ConfigMaps/Secrets, ServiceAccounts, PersistentVolumeClaims (PVCs), and the selected ingress resource (Ingress or Route). The cluster must be able to provision the required PVCs.
- A container image registry reachable by every node that may run SDS. The registry must accept the SDS image and you must have an image-loading method appropriate for the cluster (for example, the embedded container registry in a single-node k3s installation). Docker and comparable image loading tools (such as skopeo) are required to push, pull, or otherwise manage the image in the registry.
Cluster capacity and storage: Reserve, at minimum, the resources requested by the default chart values for each SDS pod.
- 8 CPUs and 32 GiB of memory per SDS pod.
- Storage that supports ReadWriteOnce PVCs, with a usable StorageClass and at least 30 GiB provisioned for SDS data and logs.
- The chart is configured with one StatefulSet replica by default.
Network and DNS:
- All nodes that may run SDS must be able to pull the SDS container image from the registry.
- Users must be able to reach the hostname configured for the Ingress or Route.
- DNS for the selected hostname must resolve to the ingress controller or OpenShift router.
- Network firewalls, cloud security groups, load balancers, any cluster NetworkPolicy objects must allow SDS-related traffic.

The SDS service exposes the following TCP ports inside the cluster:

Port	Purpose
8080	HTTP web UI and health endpoint
8443	HTTPS web UI
55555	SDS native listener

By default, the chart's NetworkPolicy allows ingress traffic to ports 8080, 8443, and 55555 without restricting source namespaces or pods. For restricted environments, add explicit from rules to limit which namespaces or pods may connect. The chart does not define any egress rules; verify that the existing cluster-wide or namespace-level egress policies permit the outbound connections required by SDS.

Download and Prepare Artifacts

In Strategy Community, in the Federated Data Connectors category, download the following artifacts for Secure Data Service (SDS):
- The Helm chart package: secure-data-service-helm.tgz
- The matching SDS container package: secure-data-service-container.zip
Do not install the chart before preparing the corresponding image. The chart contains only Kubernetes manifests; it does not include the SDS container image. Do not mix a chart from one release with a container package from a different release.

Extract the two artifacts into separate directories. For example:

Copy

mkdir -p "$HOME/sds-release/chart" "$HOME/sds-release/image"
tar -xzf secure-data-service-helm.tgz -C "$HOME/sds-release/chart"

unzip secure-data-service-container.zip -d "$HOME/sds-release/image"
find "$HOME/sds-release" -name dgs-sds.tar -o -name Chart.yaml

The container package contains dgs-sds.tar, a Docker image archive. The embedded image name includes the release build tag. Note that name before loading the image:
Copy
```
docker load --input "$HOME/sds-release/image/dgs-sds.tar"
```
This command prints the loaded image reference (including the tag). Use that reference in the next step. If dgs-sds.tar is extracted into a different subdirectory, use its actual path in the docker load command.

Make the SDS Image Available to the Cluster

Push the SDS image to a registry that is reachable from all cluster nodes, preferably a private registry.
Tag the image loaded in the previous step with your fully qualified repository name and an immutable release tag and push the image. Replace the example values with your registry, repository, and release version:
Copy
```
docker tag dgs-sds:<embedded-build-tag> \
  registry.example.com/microstrategy/dgs-sds:<release-version>
docker push registry.example.com/microstrategy/dgs-sds:<release-version>
```
For production environments, obtain the image digest after pushing and use the digest in the Helm installation.

If the registry requires authentication, create an image pull Secret in the target namespace and provide its name as image.pullSecret in the Helm values and commands used in the following steps of the next section.

For Kubernetes:

Copy

kubectl create namespace <namespace>
kubectl -n <namespace> create secret docker-registry sds-registry \
  --docker-server=registry.example.com \
  --docker-username='<registry-user>' \
  --docker-password='<registry-password>'

For RedHat OpenShift:

Copy

oc create namespace <namespace>
oc -n <namespace> create secret docker-registry sds-registry \
  --docker-server=registry.example.com \
  --docker-username='<registry-user>' \
  --docker-password='<registry-password>'

Where required, use your organization's approved secret-management process instead of storing registry credentials in a shell history or local configuration files.

Configure Installation

Create a customs value file rather than using a long series of --set options in operational scripts. Begin with the chart's values.yaml file and override at least the image and exposure settings.

For example, for Kubernetes with an existing ingress controller, see the following:

Copy

# sds-values.yaml
image:
  repository: registry.example.com/microstrategy/dgs-sds
  tag: <release-version>
  digest: sha256:<64-hex-character-digest>
  pullPolicy: IfNotPresent
  pullSecret: sds-registry # omit when the registry is public

route:
  enabled: false

ingress:
  enabled: true
  host: sds.example.com
  ingressClassName: <your-ingress-class>
  # Configure TLS according to the ingress controller and certificate process.
  # tls:
  #   - hosts: [sds.example.com]
  #     secretName: sds-tls

persistence:
  storageClass: <your-storage-class>

For Red Hat OpenShift, copy the supplied OpenShift values file and configure a Route instead:

Copy

# sds-openshift-values.yaml
route:
  enabled: true
  host: sds.example.com # optional; OpenShift generates one when empty

ingress:
  enabled: false

persistence:
  storageClass: <your-storage-class>

When using OpenShift, pass both values-openshift.yaml and your customer values file. The OpenShift values file removes fixed numeric user and group IDs so the cluster can assign an allowed identity.
Review and confirm the following settings before installation:
- image.repository, image.tag, and preferably image.digest must point to the exact SDS image for this release. When specified, the digest is applied in addition to the tag.
- If static external access is required, ensure that exactly one of either route.enabled and ingress.enabled settings is set to true.
- ingress.host must be set when Ingress is enabled. TLS termination or passthrough is controlled by the ingress controller configuration. The chart's Ingress backend uses the HTTP service port 8080.
- route.tls must align with the OpenShift router policy. By default, the Route uses edge TLS termination and redirects HTTP to HTTPS.
- persistence.storageClass must exist in the cluster and support the requested ReadWriteOnce volumes. Configure per-volume storage classes or sizes, if required.
  
  Registry credentials, SDS environment variables, and other sensitive values must be provided via Kubernetes Secrets. Do not commit password or other confidential data to the values.yaml file.
  
  The complete list of configurable values - including probes, resource limits, JVM options, affinity, Network Policy, and PodDisruptionBudget settings - is available in values.yaml.

Validate and Install

Run the following checks from the unpacked chart directory (the directory that contains Chart.yaml) before you install.

When you use --validate, helm template may require access to the cluster API.

On Kubernetes:

Copy

helm version
kubectl config current-context
helm lint .
helm template sds . \
  --namespace <namespace> \
  --values sds-values.yaml \
  --validate

On OpenShift, include both value files:

Copy

helm version
oc whoami
helm lint .
helm template sds . \
  --namespace <namespace> \
  --values values-openshift.yaml \
  --values sds-openshift-values.yaml \
  --validate

Install SDS only after the image is available in the registry and the rendered manifests have been reviewed.

Kubernetes example:

Copy

helm upgrade --install sds . \
  --namespace <namespace> \
  --create-namespace \
  --values sds-values.yaml \
  --wait \
  --timeout 10m

OpenShift example:
Copy
```
helm upgrade --install sds . \
  --namespace <namespace> \
  --create-namespace \
  --values values-openshift.yaml \
  --values sds-openshift-values.yaml \
  --wait \
  --timeout 10m
```
When multiple values files are specified, settings from earlier value files will be overwritten by the later files. Keep values-openshift.yaml first and place your customer-specific overrides second.

Verify the Deployment

Check the release, StatefulSet, PVCs, and Services using the following command:

Copy

helm status sds --namespace <namespace>
kubectl get statefulset,pods,pvc,svc -n <namespace> -o wide
kubectl rollout status statefulset/sds --namespace <namespace> --timeout=10m
kubectl get events --namespace <namespace> --sort-by=.lastTimestamp

The pod is ready only after its startup and readiness probes succeed. Confirm that the pod is running the expected image and image ID using the following:

For Kubernetes, use the kubectl command and check the Ingress and its assigned address:

Copy

kubectl get pod sds-0 -n <namespace> \
  -o jsonpath='{.status.containerStatuses[0].imageID}{"\n"}'
kubectl logs sds-0 -n <namespace> --tail=200
kubectl get ingress sds -n <namespace>

For OpenShift, use oc in place of kubectl and check the Route:

Copy

oc get pod sds-0 -n <namespace> \
  -o jsonpath='{.status.containerStatuses[0].imageID}{"\n"}'
oc logs sds-0 -n <namespace> --tail=200
oc get route sds -n <namespace>

Test the web endpoint using the configured hostname from a network that is permitted to reach it. If no Ingress or Route is configured, use a temporary port-forward from the administration workstation.
- For Kubernetes:
  Copy
```
kubectl port-forward -n <namespace> statefulset/sds 8080:8080
curl --fail http://localhost:8080/
```
- For OpenShift:
  Copy
```
oc port-forward -n <namespace> statefulset/sds 8080:8080
curl --fail http://localhost:8080/
```

Uninstall

Only use the following section if you need to uninstall SDS. If you are performing a new installation, skip the steps in this section.

The SDS data, DGS Agent logs, SDS logs, and container-state PVCs are managed by the StatefulSet and are not automatically removed when the Helm release or StatefulSet is deleted. This behavior preserves data during upgrades, but any orphaned PVCs continue to consume storage.

To remove Helm-managed resources while retaining PVCs in Kubernetes:

Copy

helm uninstall sds --namespace <namespace>
kubectl get pvc --namespace <namespace>

In OpenShift:

Copy

helm uninstall sds --namespace <namespace>
oc get pvc --namespace <namespace>

Delete PVCs only after confirming that the data has been backed up and no future installation requires it.

PVC names may differ if the release name or chart name has changed. Always list and verify PVC names before deleting them.

In Kubernetes:

Copy

kubectl delete pvc --namespace <namespace> \
  data-sds-0 logs-sds-0 sds-logs-sds-0 container-state-sds-0

In OpenShift:

Copy

oc delete pvc --namespace <namespace> \
  data-sds-0 logs-sds-0 sds-logs-sds-0 container-state-sds-0

SDS Configuration

SDS Connection to MCE or MCS Environment

Before the Intelligence server can use SDS to query the Warehouse database, SDS must be connected to the MCE or MCS environment and configured with the database login credentials (for example, username and password). To do this, the connection from SDS to MCE or MCS must be established using the Library SDS web interface:

Using a web browser, open the SDS web using the following URL templates: http://<sds-agent-host>:8080/ or https://<sds-agent-host>:8443/.

If you access the UI from a different machine, ensure that the SDS host firewall allows inbound connections on port 8080 and/or 8443. This is typically required when the Linux host has no graphical interface and is accessed remotely (for example, using a terminal session).

When accessing the HTTPS endpoint, your browser may display a Your connection is not private warning. To resolve this issue, see Fix the Connection Not Private Web Browser Error.
In SDS, click Add New.
Enter values in the following fields:
- Environment URL: Enter the Library REST URL for your MCE or MCS environment.
- Display Name: Type a descriptive name for your environment.
- Support OAuth: Choose Yes only if your Library supports OIDC (OpenID Connect) or SAML.
  
  If you choose Yes, follow the steps starting in 4a. in Configure the Connection.
Click Continue and enter your credentials.
Toggle on Enable Agent.

Database Warehouse Login Setup in SDS

SDS must be configured with the database login credentials used to access the Warehouse. This configuration enables secure database access without storing sensitive credential information in the Strategy MCE or MCS environment. The following example uses a database login credential called PostgresSDS-DBLogin.

Open SDS, go to Database Logins, and click Add.
SDS store database login credential locally. Enter values in the following fields:

You can also configure SDS to retrieve credentials from secret vaults. For more information, see Configure Secret Vaults for SDS.
- Name: Type the name of the database login. For example, PostgresSDS-DBLogin.
- Description: Optionally add additional information about the login.
- Username: The username used to connect to the warehouse database.
- Password: Type your associated password.
Click Save.

Configure Intelligence Server-to-SDS Connection in Workstation

Create a Database Login

Create a database login that maps the database login created in SDS, as described in the previous section:

Open Workstation and connect to the MCE or MCS environment that contains the Intelligence server.
In the left Navigation pane, click Data Sources.
Click the Database Logins tab and click Add New Database Login.
Enter values in the following fields:
- Use Vault: Disable this option.
- Name: Type the same database login name you used above. For example, PostgresSDS-DBLogin.
- Username: Enter any placeholder value. This value is ignored.
- Password: Enter any placeholder value. This value is ignored.
Click Save.

Create a Database Connection

Create a database connection that uses the login you created above:

SDS only supports DSN-less database connections. If you connection is currently configured using a DSN, convert it to a DSN-less connection. For more information, see Convert a DSN Data Source to DSN-Less.

In the Workstation left Navigation pane, click Data Sources.
Click the Database Logins tab and click Add New Database Connection.
Enter values in the following fields:
- Name: Type a name for the database connection.
- Driver: Expand the drop-down list and choose ODBC or JDBC.
- Host Name: Enter the host name or IP address of your warehouse database.
- Gateway Agent: Expand the drop-down list and choose the host where SDS is installed.
  
  If a Data Gateway Agent (DGS) was previously connected to your MCE or MCS environment, you may see two agent with the same name. Do not choose the agent that displays (offline). Choose the active (non-offline) agent that corresponds to the SDS agent.
- Authentication Mode: Expand the drop-down list and choose Standard.
- Default Database Login: Expand the drop-down list and choose the database login you created above. For example, PostgresSDS-DBLogin.
- Port Number: Enter the port number for your warehouse data.
- Database: Enter your database name for your warehouse data.
Click Test.
Click Save.

The database connection is ready to use in your Strategy workflows such as using dashboards, publishing cubes, and more.

If you need to enable SDS for database access in Mosaic Studio, see Use SDS for Mosaic Models.