New features

What is Data Control Tower?

Data Control Tower (DCT) is a unified data management platform used to enable API-driven DevOps workflows with Continuous Data and Compliance, and centrally manage the entire data estate for all Delphix users. The core of DCT focuses on a centralized, container-based deployment architecture with a robust API library that enables automation and management across multiple Delphix Engines. The DCT container form factor allows users to self-host on their preferred public or private cloud environment.

In addition to APIs, DCT offers a central management User Interface to visually surface curated inventories of its connected ecosystem (engines, dSources, VDBs, etc.) as well as insights in the form of reporting dashboards.

Release 5.0.1

Enhancements

• Data Scoped Access Group
  • Enhancement in Roles
    Associated permissions in roles are changed from 'string' type to 'permission object' type. For details, see the Role schema in the API References.
  • Custom Roles
    In addition to the 5 pre-seeded fixed roles (Admin, Monitoring, DevOps, Masking, and Owner), DCT provides flexibility to create new custom roles as per user need. Users (Accounts) can create new custom roles by encapsulating any combination of permissions. The custom roles can be configured through a UI configuration screen (screenshot below), in addition to a set of APIs to manage roles. For details, see the API References.
    
• Updates to Existing RBAC Model
  For better usability and allow to set more granular permissions there are following enhancements in the RBAC model: 
  • Renamed Access Aroup "Policy" to Access Group "Scope"
  • Renamed the following APIs related to Access Group actions
    • Add scope to an Access Group
      POST: /access-groups/{accessGroupId}/policies → POST /access-groups/{accessGroupId}/scopes
    • Remove scope from Access Group
      DELETE /access-groups/{accessGroupId}/policies/{policyId} → DELETE /access-groups/{accessGroupId}/scopes/{scopeId}
    • Get Access Group scope
      GET /access-groups/{accessGroupId}/policies/{policyId} → GET /access-groups/{accessGroupId}/scopes/{scopeId}
    • Update Access Group scope
      PATCH /access-groups/{accessGroupId}/policies/{policyId} → PATCH /access-groups/{accessGroupId}/scopes/{scopeId}
    • Add object tags to Access Group scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/object-tags → POST /access-groups/{accessGroupId}/scopes/{scopeId}/object-tags
    • Remove object tags from Access Group scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/object-tags/delete → POST /access-groups/{accessGroupId}/scopes/{scopeId}/object-tags/delete
    • Add objects to Access Group scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/objects → POST /access-groups/{accessGroupId}/scopes/{scopeId}/objects
    • Remove objects from Access Groups scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/objects/delete → POST /access-groups/{accessGroupId}/scopes/{scopeId}/objects/delete
  • Renamed the "everything" flag to "scope_type"
    In order to make it more understandable, we have renamed the everything flag to scope_type. There are three possible values for scope_type i.e. SIMPLE, SCOPED and ADVANCED. The value SIMPLE corresponds to everything=true and SCOPED corresponds to everything=false. The value ADVANCED for scope_type is new enhancement to setting permissions which allows users to set permissions (e.g. READ, DELETE) for an object. There is more information about ADVANCED scope in next section.
  • Access Group Scope: Advanced scope type
    In Add objects to access group scope API, now user can define permissions level checks as well for an object. For example, earlier when object_id and and object_type are provided in request payload, all permissions that are defined in scope are applied to this object. But now user can define specific permissions.
    
    API Example:
    curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scopeId}/objects' \ 

    --header 'Content-Type: application/json' \

    --data-raw '{

        "objects": [

            {

                "object_id": "1",

                "object_type": "ACCOUNT",

                "permission" : "READ"

            }

        ]

    }'
  • Add an always allowed object to Access Group scope
    Always allowed objects can be defined as objects that are always allowed for an access group scope. This can be set as follows:
    
    Add always allowed objects:
    curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scope-id}/always_allowed_permissions' \--header 'Content-Type: application/json' \
--data-raw '{
    "always_allowed_permissions": [
        {
            "object_type": "ACCOUNT",
            "permission" : "READ"
        }
    ]
}'
Response: The updated access group scope
    
    Here it means that all objects with object type ACCOUNT and permission READ are allowed with this access group scope. This will clear out matching object type and permissions, if any in objects attribute of access group scope.
    
    Remove always allowed objects:
    curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scope-id}/always_allowed_permissions/delete' \--header 'Content-Type: application/json' \
--data-raw '{
    "always_allowed_permissions": [
        {
            "object_type": "ACCOUNT",
            "permission" : "READ"
        }
    ]
}'
Response: The updated access group scope
• Masking Jobs
  • CRUD APIs, COPY, Connectors CRUD
• Masking Job Execution
  • Connector Credentials
  • Execution API

Custom Roles

• Accounts can create new instances of role encapsulating any combination of permission.
• Role name must be unique.
• Custom roles can be updated. Accounts can add or remove permissions to/from the custom roles.
• Custom roles can be deleted. (If they are not associated with any Access Group).

Release 4.0

• Environment Overview List
• Unvirtualized Source Sizing Report
• Global VDB Templates
• Scoped Access Control

UI

• LDAP/AD and SAML/SSO Configuration UI

Release 3.0

• APIs
• Cluster Node (RAC) management APIs
• Ability to disable username/password authentication globally
• LDAP/Active Directory groups
• CDBs/vCDBs APIs
• VDB Provisioning / update for EDSI (AppData) platforms

UI

• Engine registration wizard
• Access Groups
• Compliance engine page

Release 2.2

Deployment

• Introducing Kubernetes and OpenShift support

APIs

• Registration of Continuous Compliance Engines
• Masking Connectors
• “Move Masking Job”
• Masking of mainframe objects
• Provisioning enhancements for Oracle multi-tenant and RAC
• LDAP/Active Directory authentication
• Password management
• Initial access management by Permissions, Roles, Policies, and Access Groups (permissions applied to all objects of a type e.g. Stop VDB permission on all VDBs)
• Distributed tracing and logging (Trace ID propagated down call stack)
• Bulk delete of tags

UI

• Continuous Data
  • Added tag support to the Infrastructure page
  • New dSources page
  • New VDBs page
• Insights
  • Added an export behavior to the Storage Summary report
  • New dSource Inventory report
  • New VDB Inventory report
• Admin
  • New Accounts page