VMware Data Services Manager Kubernetes API

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:
    • ConfigMap
    • Secret
    • BackupLocation
    • DirectoryService
    • SQLServerCluster
    • ActiveDirectoryDomain
    • DataServicePolicy
    • MetricsTarget
    • ImageRegistry
  • Create, read and delete:
    • SupportBundle
    • LogBundle

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.

  • Read, and update specific fields (system-managed):
    • VCFANetworkSecurityConfig
    • LoadBalancerNetworkSecurityConfig

Note: Both resource types are created and deleted only by DSM’s internal provisioner, never directly by DSM Admins. DSM Admins may read them and update only the fields that control firewall enforcement: spec.enabled on VCFANetworkSecurityConfig, and spec.disabled / spec.extraClients on LoadBalancerNetworkSecurityConfig. All other fields are immutable.

DSM Users

  • Read-only access to:
    • BackupLocation
    • DirectoryService
    • ConfigMap
    • MetricsTarget

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.
  • Network Security Configuration:
    • View the singleton VCFANetworkSecurityConfig (name network-security-config) for the VCF Automation region, DSM organization, and Transit Gateway used to enforce network security for DSM database clusters, plus status visibility into detected VPCs and their load balancer IPs. Toggle spec.enabled to turn firewall enforcement on or off.
    • View the LoadBalancerNetworkSecurityConfig resources DSM automatically creates for each database cluster (one for the Kubernetes API server, one for the database load balancer). Set spec.disabled to temporarily turn off firewall rules for troubleshooting, or add IPs to spec.extraClients to grant additional clients access to the cluster.
  • 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 and later. 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.
  7. VCFANetworkSecurityConfig network-security-config
    • Singleton resource - only one instance is permitted in dsm-system - holding the VCF Automation region URN, DSM organization URN, and Transit Gateway name used to program network security (firewall) rules for DSM database clusters. Status reports detected VPCs and their load balancer IPs. Created and deleted only by DSM’s internal provisioner; DSM Admins may toggle spec.enabled only.

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.