Delphix: A Quick Refresher
Delphix is a software-defined data platform designed to automate and secure the data lifecycle. To handle data at scale without the usual operational friction, it relies on three pillars:
- Continuous Data (Virtualization) : This virtual appliance ingests production sources to create compressed dSources. You can then provision virtual clones (VDBs) in minutes. It’s not just about optimizing storage via block-sharing, it’s about drastically slashing refresh times, moving from hours of manual DB cloning to a few minutes of automation.
- Continuous Compliance (Masking) : Acting as the compliance safeguard, this virtual appliance anonymizes sensitive data (GDPR, etc.) while keeping referential integrity intact across applications. You get usable test data without the risk of a data leak or a legal headache. For more information, you can read my other blog Data Anonymization as a Service with Delphix Continuous Compliance.
- Data Control Tower (DCT) : The central Control Plane. Unlike the engines above, DCT is a SaaS platform that unifies everything through a single API. It also provides a dedicated interface where developers can manually manage their own resources in total autonomy, without needing a DBA behind them for every refresh. It effectively turns isolated instances into a programmable, self-service infrastructure.
The ABAC Approach: Beyond static roles
Access management usually relies on the RBAC (Role-Based Access Control) model. In this setup, permissions are tied to roles (like “Developer” or “Analyst”) and users simply inherit whatever their role allows. While this works fine at the start, it quickly becomes a rigid mess as projects multiply, usually leading to a “role explosion” that’s a nightmare to maintain.
ABAC (Attribute-Based Access Control) takes a different path: rights aren’t frozen into a static role anymore. Instead, they are determined dynamically based on attributes (characteristics of the resource, the user, and the environment). It’s a shift from Who are you? to What are you trying to access and does it match your current context?.
Delphix DCT: Leveraging Tags for Smarter Data Governance
The real strength of Delphix Data Control Tower (DCT) lies in its ability to leverage tags for strict resource segregation. In a sprawling enterprise environment, global visibility is rarely a feature; it’s more of a liability. By mapping specific tags to your resources, you define isolated management boundaries that actually make sense for the business.
This setup ensures that teams only see the infrastructure they are responsible for. It’s a clean way to enforce the Least Privilege principle without the administrative overhead of manual role mapping. By restricting a user’s scope to their specific tags, you eliminate the risk of someone interact with an environment they weren’t even supposed to know existed. It’s about creating a workspace where developers can be autonomous within their own perimeter, while the rest of the infrastructure remains safely out of sight (and out of reach).
ABAC in Action: Configuring Dynamic Access Control in Delphix DCT
Even when managing a massive Delphix environment, you can strictly limit a developer’s or DevOps engineer’s visibility to only the resources they actually own. Through the unified DCT platform, they get a consolidated view of their specific objects only :



In the three images above, each component is identified by the tag Team: BlogTeam. This key-value pair is directly tied to the permissions assigned to the current user. In this specific scenario, a user belonging to the BlogTeam access group is granted the following roles:

While these roles might seem overly permissive at first glance, the ABAC framework in Delphix allows for granular control. It ensures that these permissions are dynamically scoped, applying only to the specific resources that match the user’s attributes.

It is important to understand that ABAC in Delphix DCT isn’t just a “view-only” filter ; it doesn’t just dictate who sees what, it defines who can do what.
By combining roles with tag-based scopes, you can achieve surgical precision in your permissions. For instance, a developer might be granted the Provision VDBs right on all resources tagged with Team : BlogTeam, while only having Refresh or Snapshot capabilities on VDBs tagged with Environment: Integration. This ensures that even within the same project, critical actions are restricted to the right people at the right time, without ever needing to touch a single manual access list.
The true power of Delphix DCT lies in its ability to transform a basic administrative task (tagging) into a robust automated governance engine. It provides administrators with absolute control while ensuring developers operate within a streamlined interface, strictly confined to their specific workspace.
DCT: Moving from GUI Management to API-First Governance
Integrating Delphix into a modern CI/CD pipeline means saying a final goodbye to manual clicks. Thanks to DCT’s API-First architecture, every resource is treated as a programmable object. By using tags as dynamic filters, you stop managing environments by their names or IP addresses and start orchestrating them by their business properties.
The real beauty here is the ability to script complex workflows in just a few lines of code. Instead of manually triggering a refresh for ten different test databases (a task as tedious as it is prone to error) your pipeline can simply query the API to identify every resource tagged with Team : BlogTeam and fire off the operation simultaneously. This approach doesn’t just save precious time; it ensures total reproducibility while eliminating the human factor.
To give you a concrete example, the following Python snippet shows how to authenticate with the DCT API and retrieve details for all VDBs associated with the specific tag Team : BlogTeam :
import requests, urllib3, logging
from typing import List, Dict, Any
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
logging.basicConfig(level=logging.INFO, format="%(levelname)s: %(message)s")
logger = logging.getLogger(__name__)
class Config:
dct_url = "https://<DELPHIX_ENGINE_URL>/dct/v3"
username = "YOUR_USERNAME"
password = "YOUR_PASSWORD"
class DctApiClient:
def __init__(self, cfg):
self.cfg = cfg
self.token = None
def authenticate(self):
try:
r = requests.post(f"{self.cfg.dct_url}/login",
json={"username": self.cfg.username, "password": self.cfg.password}, verify=False)
self.token = r.json()["access_token"]
logger.info(f"Connected (expires in {r.json().get('expires_in')}s)")
return True
except Exception as e:
logger.error(f"Authentication failed: {e}")
return False
def headers(self):
return {"Authorization": f"Bearer {self.token}", "Accept": "application/json"}
def get_vdbs_by_tag(self, tag_key: str, tag_value: str) -> List[Dict[str, Any]]:
vdbs = requests.get(f"{self.cfg.dct_url.replace('/dct/v3', '/v3')}/vdbs",
headers=self.headers(), verify=False).json().get('items', [])
filtered = [v for v in vdbs if any(t.get('key')==tag_key and t.get('value')==tag_value
for t in v.get('tags', []))]
logger.info(f"{len(filtered)} VDB(s) found")
for v in filtered:
status_color = '\033[92m' if v.get('status','').lower()=="running" else '\033[91m'
print(f"\n{'='*35}\n{v.get('name'):20} | {status_color}{v.get('status')}\033[0m\n"
f"ID: {v.get('id')}\nType: {v.get('database_type')}\n{'='*35}")
return filtered
if __name__ == "__main__":
client = DctApiClient(Config)
if client.authenticate():
client.get_vdbs_by_tag("Team", "BlogTeam")
And the result :
INFO: Connected (expires in 86400s)
INFO: 1 VDB(s) found
===================================
VDB_BLOG | RUNNING
ID: 1-MSSQL_DB_CONTAINER-190
Type: MSSql
===================================
Conclusion: Bridging Governance and Agility
In summary, implementing ABAC within Delphix Data Control Tower marks the end of an era where security was synonymous with administrative friction. By using tags as the foundation of your governance, you transform a complex data infrastructure into a granular, secure self-service ecosystem. It is no longer the tool dictating your processes, but your business requirements dynamically driving access control.
A major advantage of this model is the seamless onboarding of new developers. Instead of manually configuring complex permissions for every newcomer, simply assigning the appropriate tags allows them to be productive instantly, with immediate and secure visibility over their specific scope.
This approach opens the door to advanced use cases that we have only scratched the surface of here:
- Automated Self-Service: Integrating tag creation directly into your provisioning processes so that resources are immediately isolated within the correct perimeter.
- FinOps & Showback: Leveraging this same tagging logic to accurately allocate storage and compute costs by project or team.
- Dynamic Data Masking: Automating masking jobs based on tag criticality (e.g.,
Criticality : Confidential), ensuring no sensitive data leaves the production environment without protection.
And you? How are you managing access in your non-production environments for developers? Is API automation already at the heart of your DataOps strategy? Let’s discuss it in the comments, or feel free to reach out to explore these topics further.