DSM System Namespace

DSM System Namespace

DSM System Namespace

Overview

The dsm-system namespace is designated for storing and managing system-wide secrets and configurations in DSM. It is intended to centralize system resources, ensuring they are secure and easily accessible for administrative tasks. DSM Admins have the ability to create, update, and read resources in this namespace, while DSM Users can only read specific resources.

SQLServerClusters and ActiveDirectoryDomains reside in the dsm-system namespace as infrastructure managed exclusively by DSM Admins. DSM Users cannot read or list these resources directly. They interact with them only through assigned DataServicePolicies.

Below, you’ll find a complete list of resources in the dsm-system namespace, and the operations each user type is authorized to perform

Capabilities

DSM Admins

  • Create, update, read, delete:

    • ConfigMaps

    • Secrets

    • BackupLocations

    • DirectoryServices

    • SQLServerClusters

    • ActiveDirectoryDomains

    • DataServicePolicies

    • MetricsTargets

    • ImageRegistries

  • Create, read and delete:

    • SupportBundles

    • LogBundles

Note: LogBundles reside within the same namespace as the data service from which their logs were generated. DSM Users can read LogBundles from non dsm-system namespaces.

DSM Users

  • Read-only access to:

    • BackupLocations

    • DirectoryServices

    • ConfigMaps

    • MetricsTargets

Key Actions for DSM Admins

  • ConfigMaps and Secrets:

    • Create or update trust bundles.

    • Manage system-wide backup locations.

    • Configure system-wide LDAP directory service.

  • SQLServerClusters and ActiveDirectoryDomains:

    • Manage SQLServerClusters and ActiveDirectoryDomains.

    • Create DataServicePolicies and namespaces that allow regular users to place SQLServerDatabases on pre-existing SQLServerClusters.

  • DataServicePolicies:

    • Define policies that control what infrastructure, backup locations, and configurations users can access.

    • Use matchCriteria to apply policies to specific namespaces based on namespace properties.

    • Policies are enforced through DataServicePolicyBinding resources created in user namespaces.

    • Support policies for PostgreSQL, MySQL, and SQL Server databases.

  • Monitoring and Observability:

    • Configure MetricsTarget for Bring Your Own Monitoring (BYOM) integration.

    • Generate SupportBundle and LogBundle for diagnostics and troubleshooting.

  • Image Management:

    • Configure ImageRegistry resources for SQLServerCluster deployments (typically pointing to mcr.microsoft.com/mssql).

  • User Access:

    • Allow users to read backup locations, directory services, and ConfigMaps.

    • Restrict users from reading Secrets.

Pre-defined Well-Known Resources

  1. ConfigMap trusted-root-ca

    • Contains the list of trusted root CAs used by DSM as a trust bundle.

  2. Directory Service ldap-default

    • The directory service used by DSM Appliance and Database clusters for authentication.

  3. ConfigMap vcenter-ca

    • Contains the server issuer CA of the vCenter server connected to DSM.

  4. BackupLocation default-provider-log-repo

    • An S3-compatible object store for saving log bundles generated on the Provider VM.

  5. BackupLocation default-provider-backup-repo

    • An S3-compatible object store for periodically backing up the Provider VM database.

  6. ConfigMap advanced-system-config

    • Contains advanced system-wide configuration options that apply to the entire DSM system. These settings are managed by DSM Admins and affect system behavior across all data services and clusters. Changing default values must be done with caution. Supported keys:

      • default-namespace-allowed-for-new-data-service-instance (boolean, default: "false"): When "true", allows Postgres and MySQL clusters to be created in the legacy “default” namespace. When "false" or not set, clusters must be created in dsm-managed namespaces.

      • postgrescluster-allow-non-ssl-system-users (boolean, default: "false"): When "true", allows non-SSL connections for system users (admin user, monitoring user) in Postgres clusters. This overrides the default SSL enforcement for system users introduced in DSM release >= 9.0.2. Applies to new clusters immediately; existing clusters will pick up the change on next update.

      • mysqlcluster-router-memory-override (string, default: "256Mi"): Either a standard kubernetes quantity (e.g, "512Mi") to be used for all vmClasses, or a percentage (e.g., "10%") of the total memory of the vmClass of the cluster. Percentage values are allowed only up to 50%, while absolute values should be carefully set not to exceed 50% of the smallest vmClass to be used for mySQL HA. This setting overrides the default memory allocation for MySQL Router pods. Typically only required for very high connection concurrency (max_connections far above 1000).

      • dsm-endpoints-cert-validation (string, default: "latest"): Controls the certificate validation mode for TLS certificates used by DSM appliance and all DSM-managed database endpoints. Valid values are "latest"(enforces digitalSignature KeyUsage requirement and FIPS 140-3 compliant cryptographic standards for all database engines and DSM system components) or "pre91" (enforces KeyUsage validation only for PostgreSQL endpoints and the newly introduced fips compliance validations are not applied, providing backward compatibility with pre-9.1 deployments). Starting with DSM 9.1, only RSA (minimum 2048 bits) and ECDSA algorithms are supported. Ed25519 and P-224 elliptic curve are rejected for all DSM appliance and all DSM-managed database endpoints. Server certificates must either include digitalSignature in the KeyUsage extension or omit the KeyUsage extension entirely. If not specified or if the ConfigMap does not exist, the system defaults to “latest” mode.

By managing these resources, DSM Admins ensure that the DSM environment remains secure and properly configured, while allowing DSM Users appropriate access to necessary configurations and services.

DataServicePolicy Workflow

DataServicePolicies are a key mechanism for controlling user access to infrastructure resources. The workflow involves defining policies in the dsm-system namespace and enforcing them in user namespaces via bindings.

  1. Policy Creation (in dsm-system):

    • DSM Admins create DataServicePolicy resources in the dsm-system namespace.

    • Policies can define allowed infrastructure (e.g., SQLServerClusters), backup locations, allowed database versions, and configuration constraints.

    • Policies are restrictive: usually, they define what is allowed. If multiple policies apply, the result is the intersection of allowed capabilities.

  2. Defining Match Criteria:

    • Each policy includes matchCriteria (key, operator, values) to determine which user namespaces it targets.

    • Common criteria include VCF Automation organization ID (e.g., vcfa.vmware.com/org: urn:vcloud:org:3bb1cbe3-ce61-47be-b85e-29a65532758c), or custom labels (e.g., environment: production).

  3. Namespace Setup (User Namespaces):

    • When a user namespace is created (via the DSM Portal or the VCF Automation Portal), a DataServicePolicyBinding resource named binding is automatically created in that namespace.

    • This binding contains namespaceProperties (key-value pairs) that describe the namespace, e.g., its VCF Automation organization ID or custom labels (e.g., environment: production).

    • Note: In standalone manual setups, an Admin may need to create this binding manually.

  4. Policy Resolution:

    • DSM continuously compares the namespaceProperties of the binding against the matchCriteria of all DataServicePolicy resources in dsm-system.

    • All matching policies are aggregated using a Logical AND:

      • Allowed Lists (e.g., versions, backup locations): The effective list is the intersection. (e.g., Policy A allows v14, v15; Policy B allows v15. Result: only v15 is allowed).

      • Required Configs: The effective config is the union of requirements.

  5. User Interaction & Enforcement:

    • Users create database instances in their namespaces.

    • DSM validates the request against the calculated effective policy.

    • If the request uses a disallowed resource (e.g., a SQLServerCluster not in the allowed list) or a disallowed version, the creation is rejected.