Getting started
Planning your deployment
Data Control Tower (DCT) represents a Delphix-wide control plane. It simultaneously powers data governance, automation, and compliance workflows to enable the efficient operation of a broad, complex Delphix deployment at scale. In order to deliver scalability, service-level performance tuning, and robust resiliency, DCT leverages container technology to deliver a bespoke experience for administrative teams based on their own internal guidelines.
Before starting a DCT deployment, please contact your enterprise IT organization to determine what container platforms, configurations, and policies apply for container-hosted applications. It is helpful to include a container administrator as part of the DCT install process.
Container platform support
Data Control Tower (DCT) supports the most popular distributions of Kubernetes and OpenShift. If you do not see your distribution or platform of choice, please reach out to your account team for more details.
DCT is designed to run and is supported on any Certified Kubernetes platform that supports Helm. The product is also OCI-compliant and may use any container runtime within a certified Kubernetes platform that implements the OCI Runtime Specification including CRI-O, Docker, and Podman.
Delphix regularly tests against a range of popular Kubernetes platforms with the goal of covering a representative sample of implementations. The following Kubernetes platforms have been explicitly tested by Delphix and are recommended for use: MicroK8s, AWS EKS, Azure AKS, and OpenShift on VMWare vSphere.
Kubernetes
DCT currently supports all popular deployment models of Kubernetes as long as the service runs a minimum of Kubernetes 1.25 and above. This includes Amazon Elastic Kubernetes Service (Amazon EKS), Azure Kubernetes Service (AKS), and beyond.
OpenShift
DCT also supports all popular deployment models of Openshift as long as the service runs a minimum version of 4.12 or above. This includes Red Hat OpenShift on IBM Cloud and any other cloud provider’s service.
Docker Compose
DCT supports Docker Compose but only recommends using this platform for testing/non-production purposes due to the inherent limitations to deployment scalability. Note - DCT has documentation on migrating deployments from Docker Compose to Kubernetes and Openshift.
Data Control Tower deployment architecture
Whether an organization wants to deploy a Data Control Tower (DCT) per business unit (organizational silos), per network (datacenter-specific DCT), or globally (the most common option), DCT can adapt to many deployment scenarios.
Delphix recommends to deploy a single, global DCT for all Delphix Engines, for the purposes of achieving a single control plane and data governance solution.
DCT-based communication is lightweight, requiring simple commands or a small telemetry payload to facilitate most workflows. The below graphic demonstrates this style of communication:
DCT simply logs into the engines as a user would and leverages engine APIs to perform commands or extract metadata.
DCT requires HTTP/HTTPS to facilitate communication with engines and requires ports 80/443 to reach engines in other networks.
DCT does not directly interface with business-critical databases, it will only communicate with engines to perform operations and inquire about system statuses. The Delphix Engine, which is generally co-located with your data, does all the heavy lifting.
Plan your tagging strategy
DCT tags serve as the Delphix-wide business metadata system. These Key:Value pairs can be applied to any object and used for search and filter in virtually every DCT workflow, from automation to administration, all the way to access control.
It is paramount to develop a tagging strategy prior to deployment in order to develop a scalable metadata solution.
Some examples of popular tagging strategies:
Theme | Sub-topics | Tag (Key:Value) example |
|---|---|---|
Owner | Application, Business, Project, Team (scrum, QA,…) | (Owner: Finance App), (Owner: AppTeam Alpha), (Owner: John Doe), … |
Application | (Application: Alpha) | |
Environment | (Environment: Non Production) | |
Location | Data Center, Region, Name, Cloud | (Geo: West Coast), (Data Center: Azure WC), … |
In addition to designing which tags to implement, please consider who will have access to creating tags (i.e. developer vs admin-only, etc.), which will impact how teams are able to collaborate with one another.
Also, Delphix recommends that the DCT administrative team creates Delphix-wide documentation on these tagging standards to reduce the risk of deviation.
Plan your Access Control strategy
DCT implements a model found in other types of software called Attribute Based Access Control (ABAC). This model is incredibly flexible, but requires detailed configurations to perfect your use cases. In DCT’s model, there are four entity types (defined below). Familiarize with each entity, as they are the foundational blocks of DCT’s ABAC model.
Entity | Description | Managed by |
Accounts | A single or shared user who can authenticate with DCT (UI or API). | Create manually or via Identity Provider (IdP), such as SSO or LDAP. Accounts are independent of Delphix Engines. |
Access Groups | A collection of accounts that share one or more characteristics, such as a Team or Permission set. Equivalent to an Active Directory group. | Manually created. Populated manually or via the |
Roles and Permissions | The collection of read, write, and delete permissions forms a reusable, named role. | Some roles are provided out of the box, but Admins can build their own from the available permissions. Individual permissions are immutable. |
Objects | Units, such as VDBs, Bookmarks, and Environments, that are managed across the Delphix Platform. | Automatically identified by DCT from the connected engines. Assigned to Roles via various models. The CD and CC Engines supply these objects. |
Each entity is linked to another through manual or automated assignment. A manual (or direct) assignment is a good approach for early implementations, however, that can be challenging to maintain as teams grow. As an alternative, tagging is recommended to perform automatic assignments based on your custom configuration. The below diagram shows how each entity is linked together. The directions below start with Accounts creation to Access Groups with Role assignments, and finish with Object mappings.
Understanding your team structure is imperative to identify the best access model. Usually, organizations have existing groupings defined in their Identify Provider (IdP). These groups are typically organized in one of two ways:
A team dedicated towards a central goal (such as a Product Development team).
A group of individuals with similar permissions (such as Security Administrators).
Understanding the purpose of each group should be a guide in how the Roles and Permissions are designed. For example, the Alpha product development team might have full permission to manage existing VDBs and create new bookmarks for their team’s “Alpha” objects. On the other hand, Security Admins might have sweeping read and disable access across the entire platform to ensure compliancy. Iterating through each Access Group and designing custom, but re-useable roles, based on the Principle of Least Privilege, will produce a streamlined rollout.