DCT Access Control Implementation

Summary

Data Control Tower (DCT) fundamentally changes how application teams are governed across the Delphix Platform to ease expansion and management burden. Previously, Delphix administrators were focused on managing individual user-level access on each engine. This made it difficult as teams increased their data set requirements. This inevitably led to more time managing engine access and not rolling out test data management (TDM) practices. Now with DCT, all users are managed and access their data sets through a centralized server. This makes it easier for administrators to manage the Delphix Platform and application teams to utilize the self-service capabilities.

To take advantage of DCT’s new capabilities, Delphix administrators will implement a centralized Attribute Based Access Control (ABAC) model. This is performed by consolidating permission management from the engines to DCT, implementing Access Group policies, and assigning Object tags. The flexibility of this approach ensures your company’s required security model can be maintained or even further refined. 

The below picture attempts to show the shift in access models. In the original Engine Model, the engines were isolated from one another. No access control mechanisms were shared between Engines. In the DCT Model, Delphix administrators will manage applications teams directly through DCT. Those application teams will log directly into DCT. Only administrators will log into the Engines for advanced usage.

Note: Those familiar with DCT SaaS, not pictured here, might recognize that it directly modified the access model on the Delphix Engines. The new DCT Model does not do this. All Delphix Engine permissions are left untouched.

The blog aims to help newer DCT administrators who are (a) configuring Delphix and DCT for the first time or (b) connecting DCT to an existing set of Delphix Engines. Follow the complete directions to understand DCT’s ABAC model and the necessary building blocks to define the proper model for your teams.

Prerequisites

• [Required] Installation of Data Control Tower (DCT).

• [Recommended] One or more connected Delphix Continuous Data (CD) or Continuous Compliance (CC) Engines.

Access Model Overview

Data Control Tower implements a model that you might find in other types of software called Attribute Based Access Control (ABAC). This model is incredibly flexible but requires detailed configuration to perfect your use cases. In our model, there are four entity types which are defined below. Understand each entity as they are the foundational blocks of DCT’s ABAC model.

Each entity is linked to another through manual or automated assignment. A manual (or direct) assignment is a good approach for early implementations. However, it can be challenging to maintain as teams grow. As an alternative, Tagging is suggested as it performs 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) a team dedicated towards a central goal (such as a product development team) or (b) 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.

Directions

Summary: By the end, you will have implemented a simple Access Model for one group that will shift from per-engine to centralized DCT management. All actions should be performed as an Administrator. You will then know how to expand across the organization.

The directions are split into four sections based on the entity types:

1. Accounts
2. Access Groups
3. Roles
4. Objects

1. Accounts: Manual, LDAP/AD, or SSO/SAML

Goal: Import or create user accounts. Complete either the Manual or LDAP/SSO configuration.

Manual (User List)

Navigate to Admin > Accounts, click the “+ Account” button, and complete the form.

Manual accounts are great for testing user access or providing a service account. Take note of the checkboxes by which you want this user to access DCT. 

When you have specified all required values, select the “Create Account” button. By default, this user will have no permissions.

LDAP/Active Directory or SSO/SAML (3rd Party Service)

Navigate to Admin > Authentication, click “Edit” for either LDAP/AD or SSO/SAML, and complete the form. Ensure “Auto-create Users` is enabled. It can be disabled at any time.

If you need guidance on how to configure, follow the directions here:

• LDAP/AD Directions

• SSO/SAML Directions

Once configured, Accounts will be automatically created when a user successfully logs in. 

Note: This is functionally different from the old Engine model. Previously, the Account was created manually before they could log in.

Recommended: LDAP/Active Directory Domains

It is highly recommended that we also configure group membership during this stage. By defining the metadata attributes in the optional `domains` fields, DCT can automatically assign users to Access Groups. If configured correctly, you will see an automatically generated `login_groups` tag on recently logged-in accounts. If an Account does not have the tag, then (a) the Domain configuration is invalid, or (b) they should re-login. The `login_groups` tag is the only tag that cannot be specified on an Account manually. 

LDAP/Active Directory Domains Groups Directions

Example Account with the `login_groups` tag.

Please test these new accounts out by logging in on another browser. By default, these accounts will not have any permissions and not see anything. In the following steps, we will give them access. In addition, if configured, we’ll take advantage of `login_groups` or a custom tag.

2. Access Groups: Creation and Account Assignment

Goal: Create an Access Group and assign Accounts directly or through Tags. 

Access Group Creation 

Next, navigate to the Admin > Access Groups tab, select the “+ Access Group” button, and complete the presented form. As described previously, these groups are based on existing teams or users with similar access. If you successfully configured the Active Directory’s Domain Groups, you can specify the `login_groups` tag and value here. Or specify a custom Tag, such as “Team: Alpha”.

You can also select Roles if you already know which should be applied. Otherwise, ignore it.

Submit the form once you are happy with your new group.

Note: Unlike an Account, you can specify the `login_groups` tag on an Access Group shown in the picture above.

On completion, you will be presented with a page similar to the one below. Unfortunately, it’s empty. Let’s add some associated Accounts now.

Manual (Direct) Assignment

Select the “+ Manually Add Accounts” button, select the desired Account, and then “Add Account”. Immediately, you’ll see it presented in the Associated Accounts list.

This is a good solution for quick management. However, it can be cumbersome as usage grows. Therefore, we recommend tags!

Tag Assignment

First, navigate to the Admin > Accounts tab and select an existing Account. (Feel free to create another one!) Once selected, add a custom Tag such as ‘Team: Alpha”. If one already exists on the Account, such as “login_groups”, remember it. 

Next, navigate back to the Access Group, select the Tag Mapping’s “Edit” button, and specify that same Key: Value pair. It might look similar to the below picture.

In this example, the “Team: Alpha” and “login_groups: Alpha” were added through the Access Group’s Tag Mapping widget. If configured successfully, your Access Group might look similar to the below picture. If you remove the Access Group or Account’s tag, you will see Account automatically removed from this listing.

Note: The “login_groups” tag functions identically to a custom tag within the Access Group. Again, the only difference is that it's automatically assigned to the Account.

This section taught us how to organize Accounts into different groups. This allows us to keep permission sets separated. Feel free to experiment with new Access Groups, Tags, and Accounts. If you still need additional pointers, review our Access Groups Documentation.

3. Roles: Creation and Assignment

Goal: Investigate existing Roles, create a new Role, and then assign them to your Access Group.

Role Investigation and Creation 

Navigate to the Admin > Roles tab. Here we see a list of DCT’s default Roles. Each role has its selection of Permissions, such as Read VDB, Delete Bookmarks, Modify dSources, etc. Select “View” on the “devops” role to see its permissions.

On the left-hand side, you can see a description, the Access Groups it’s currently a part of, and any assigned Tags. On the right-hand side, is the complete list of permissions. For example, you can see here that the “devops” role has “Manage Tags” and “Read” permissions on the CDBs objects. These various permissions make up the Role’s identity. 

Note: DCT’s default roles are immutable.

Role Creation 

Now we understand what it’s composed of, let’s create one. Navigate back to the Admin > Roles tab and select the “+ Role” button. Give the Role a custom name, sample description, and add all the permissions you want. In my simple example, I gave it the “VDBs  > Read, Refresh, and Manage Tags” permissions. If you need to grant permission for the entire category, select the header checkbox, such as “Access Groups” or “Bookmarks”. If you only want a portion of that Object group, then click the little arrow icon to open up the complete set of options and select the targeted permissions. 

Once happy with your selection, click “Create”. You can modify your Permissions further on the presented page.

Role Assignment

Roles, by themselves, provide no access. You must first assign them to an Access Group and a set of Objects before their permissions are applied to an Account. Let’s do the first part now. Navigate back to the Admin > Access Groups tab and “View” your previously created Access Group. Select the “Roles” subtab and then “Edit” within the Roles widget.

Now you can assign default Roles, such as “devops”, and your newly created Role. You might recall that Role assignment was also possible during Access Group creation. On Save, your Access Group might look like the following.

Immediately on assignment, all users within the Access Group will now have the permissions assigned to them through these roles. (Since you are currently an Admin user, you must log in as your test Account user.) However, you might notice that this user has full access to every object on DCT. The following section will define the Role scoping modes and refine the Account Object access.

4. Objects: Refine Permission to targeted objects

Goal: Refine the permission model through Simple and Scoped (Direct and Tag) Object assignment modes.

Every Access Group’s Role has its own set of Objects to which the permissions are applied. In the previous section, we defined the permissions, and now we select the Objects. Objects are assigned in three different modes. They are listed below with their method of application:

1. Simple - All Objects within DCT.

2. Scoped

1. Tags - Objects with matching Tags.

2. Direct - Objects manually assigned.

3. Advanced Scoped - Objects are assigned directly on the permission action (such as Read Bookmark, Edit Bookmark, or Delete Bookmark) using Tags or Direct Assignment.

We will work through the first two in this post, Simple and Scoped. Advanced is easier to comprehend afterward and a solid self-lead challenge. Before diving into this section, we recommend that your DCT server has a handful of objects, such as Bookmarks or VDBs.

Simple 

If you have been following the post steadily, you should have two Roles assigned to your Access Group. In my example I have “devops” and “Limited Monitoring”. Both are given the “Simple” mode by default. We can see the breadth at which this Role governs by selecting anywhere on its row and then the “Preview” button on the right-hand side. 

In this example, we select the “Preview” list for Bookmarks. It displays every Bookmark this role has access to and the method to which they are applied. If we wanted to validate, we could log in as a user on this Access Group and verify the permissions are applied. However, this is an easier way for Administrators to confirm without switching logins. Because this is a “Simple” scope, every object is available, so this view is not particularly intriguing. In the next part, we’ll refine our Role.

Note: If you do not see any objects listed in the “Preview” widget, that object might not be available to DCT. This could be because (a) engines are not connected,  (b) the DCT-only object (such as Bookmarks or VDB Groups) is not created, or (c) permissions are being enforced correctly.

Scoped - Direct

Let’s change the mode to “Scoped” and target a subset of VDBs. On the Access Group > Roles tab, select the Action > Edit button of your chosen Role. 

A new wizard will appear with the Simple, Scoped, and Advanced Scoped options. Change the Role’s mode from “Simple” to “Scoped”. Skip the “Add Tag Mappings” for now and select “Next” to move to “Add Objects”. You will be presented with a long list of the objects available to DCT. This is where you can manually assign specific DCT objects. 

Scroll down the Object type list and select VDBs. Next, choose the “Manually add VDBs” radio button and, on the right-hand list, select a couple of VDBs. Feel free to add other available Objects too. When happy with your selection, press the “Submit” button. This set of actions should change the Role’s “Simple” mode to “Scoped” mode. Let’s verify by, again, opening the Role’s row, scrolling to your chosen Object Type, and selecting the VDBs’ “Preview” button. 

In my example, the same three VDBs I selected during permission configuration are shown here. If you want to verify manually, log in as your other test user and confirm.

Note: Any other Roles or Access Groups assigned to this user might affect its visibility. So if you do this test, ensure it's not accidentally pulling in another permission set. 

Scoped - Tags

Direct Assignment is a solid strategy for early onboarding and one-off requirements. However, as we expand our consumption of Delphix, I suggest leveraging the Tagging mechanism to assign permissions quickly. Similar to the Account & Access Group’s “login_groups” tag, we can assign tags to Objects and Roles to immediately grant or restrict access. This is the recommended approach for a robust production implementation. 

Before jumping back into a Role, navigate to the top-level Data >VDBs tab. (If you don’t have any VDBs, select another tab with available objects.)  Here identify a test object and select the “Add Tags” button.

In this form, we assign a simple Key-Value pair. This pair helps govern access and maintain the organization of the Delphix Platform. I’ve selected the “Team: Alpha” and “Environment-Dev” pairs in my example. Repeat the process for a couple of other objects using similar or different Key-Value pairs. As I explained earlier in this post, we can define and create an organizational structure in many ways. If you prefer other pairings, please experiment, such as with Geography, Age, DB Type, or Importance.

Next, let’s take advantage of the created tags in the Access Model. Navigate back to your test Access Group, select the Roles tab, and edit the Role we modified previously. Because “Scoped” is already chosen, press the “Next” button, but this time stop on the “Add Tag Mappings” view. Similar to your Object’s tag assignment, specify one or two of the same Key-Value pairs here.

In my example, this process will assign the Objects with the chosen “Team: Alpha” tag to this “devops” Role. Thus, granting the set of permissions defined by “devops”. Finally, we can verify again by completing the form and previewing the Role.

In my example, we can see a mix of objects assigned to this role through Tags and Manual (direct) assignments. 

At this point, challenge yourself by adding and removing tags to different Roles and Objects to understand the flexibility of the ABAC model. If you need a deeper dive into Tags, read our documentation here.

Closing

At this point, you should have sufficient knowledge to implement DCT’s Attribute-Based Access Control model. You successfully created a test Account, assigned it to an Access Group, gave it power through its Role, and made it applicable to designated Objects. This is a grant foundation to create new Access Groups and assign targeted Roles for Application, DevOps, or Administrative teams. Or expand the automated control through the Account’s automated “login_groups” tag or Object’s custom tags. The tight definition of these entities will ensure strong security practices across the Delphix Platform.

If you have any questions, please submit a comment below. I’ll be happy to answer it!

Frequently Asked Questions

Question: On every Account, Access Group, and Role object, I see an Access tab. What is that?
Answer: It shows which Accounts and Access Groups have permission to Create/Modify/Delete that specific object. This same Access tab exists on VDB, dSources, Environments, etc.

Question: Can I still log into my Delphix Engines? Does DCT affect Engine SSO?
Answer: Yes, you can still log into your Delphix Engines. No, DCT does not affect the Engine’s authentication model. Maintain the standard Engine authentication model to leverage your Delphix Engines directly.