DSM 9.0.2 – Aria Automation plugin changes to support new RBAC features

VMware Data Service Manager 9.0.2.0 has achieved General Availability (GA) status, and is now readily accessible from the Broadcom Download Portal. You can see the full DSM 9.0.2 release notes here. In this post, I want to revisit our efforts to integrate DSM with Aria Automation. It is true to say that most of our efforts are going into integrating VMware Data Services Manager 9.x with VMware Cloud Foundation Automation 9.x. However, many customer are still on their journey to VCF 9.x, and continue to use earlier versions of our products.  One such product that our customers are still using Aria Automation. To accommodate these customers, the DSM team has developed a plugin for Aria Automation. This enables our customers and their users to provision databases, on demand, from the Aria Automation Service Broker catalog, giving all of the added benefits associated with DSM provisioned databases (automated backups, lifecycle management, certificate management, etc). I have blogged about earlier versions of this integration with Aria Automation in the past, as you can see here, but there have been some important changes to the DSM RBAC (Role Based Access Control) in recent releases which required an update to the DSM plugin for Aria Automation. In a nutshell, the new RBAC  feature introduces the concepts of namespaces and Data Service Policies into native DSM. In the past, databases were provisioned to a ‘default’ namespace. Now they are provisioned to the namespace with which the user/database owner is associated. The namespace & Data Service Policy control which users are allowed to access which data services and versions, and which vSphere resources to consume when they provision the data services. Essentially we are aligning the standalone DSM with the RBAC found in VCF Automation. Let’s see what those changes are next, and how they affect the integration of the DSM plugin in Aria Automation.

Prepping DSM for Aria Automation integration

Let’s say, for example, I want my user dragomir to deploy certain versions of Postgres databases to the engineering-ns namespace, my user christos deploy certain versions of Postgres databases in the sales-ns namespace and my user paudie to deploy certain versions of Postgres databases to the marketing-ns. I want to achieve this via requests to provision a DBaaS catalog item in my Aria Automation Service Broker. The steps to implement this in DSM by a DSM administrator would be:

1. Assuming that these are Active Directory users, enable Directory Services in DSM & import the different AD groups (engineering, marketing, sales) containing the users into DSM as Directory Service Groups under Permissions. Alternatively, you could use local users in DSM if you wish.
2. Create different namespaces for the different groups of users (engineering, marketing, sales) and, if using Active Directory, add the appropriate Directory Service Group to the namespace.
3. Create Data Service Policies which associates the different namespaces with the permissions to provision data services. Choose the data service, which versions of service the users/groups are allowed to provision, select the appropriate infrastructure policies, select appropriate backup locations, etc.

For the purposes of this post, I have the following AD users configured in DSM:

Checking Active Directory – Users and Computers for dragomir, I can see here is in the correct AD group, DSMUsers-Engineering:

By checking the DSM Portal as a DSM Admin, I can also verify that the DSMUsers-Engineering AD Group has been added to the engineering-ns namespace in DSM:

Lastly, we can check the Data Service Policy that engineering-ns has been added to. This makes the relationship between the users/namespace and the data services and versions that they are allowed to provision. Here is a snippet of the DSP, showing that we are granting the members of the engineering-ns the ability to provision versions 16 & 17 of Postgres.

The relationship between Data Service Policy and Namespace can be shown as the following:

At this point the DSM side of things has been setup. Later on, we will see how to add these users to Aria Automation,  give them Service Broker user roles, and assign them as members of a Projects. These steps will allow them to provision databases to their own DSM namespaces through Aria Automation.

Aria Automation config.yaml changes

The config.yaml, which contains the configuration setting to integrate DSM with Aria Automation, now contains additional fields to map DSM Namespaces to Aria Automation Projects in version 9.0.2. For my particular setup, I have 3 users in different DSM namespaces that I want to be able to provision databases from Aria Automation. So I will have to create 3 different Projects in Aria Automation to achieve this:

Here is an example of the config.yaml which has the new project_to_namespace entries defined. Note that the DSM plugin for Aria Automation will only create the SVC_DSM_PROJECT referenced in the config.yaml manifest. It does not create the additional projects listed in the project_to_namespace in Aria Automation. These will need to be done manually by an Aria Automation admin after the plugin installer has been run.

---
dsm_hostname: 192.168.0.1
dsm_user_id: 'dsmadmin@ams.local'
dsm_password: 'VMware123!'
aria_base_url: https://vra.rainpole.com
orchestrator_base_url: https://vra.rainpole.com
aria_username: 'cormac'
aria_password: 'VMware123!'
org_id: 08969e76-5e6c-4581-9cf6-19c06384a9b2
blue_print_name: SVC DSM DBaaS
abx_action_name: SVC-DSM-DB-crud
cr_name: SVC_DSMDB
cr_type_name: Custom.DSMDB
env_name: SVC_DSM_ENV
project_name: SVC_DSM_PROJECT
default_namespace: marketing-ns
project_to_namespace:
  SVC_DSM_PROJECT: default
  SALES_DSM_PROJECT: sales-ns
  ENG_DSM_PROJECT: engineering-ns
  MK_DSM_PROJECT: marketing-ns
skip_certificate_check: 'False'
dsm_root_ca: |
-----BEGIN CERTIFICATE-----
MIIDcDCCAligAwIBAgIGAZrZgFtWMA0GCSqGSIb3DQEBCwUAMFkxCzAJBgNVBAYT
AlVTMQwwCgYDVQQKDANEU00xFTATBgNVBAsMDERTTSBQcm92aWRlcjElMCMGCSqG
SIb3DQEJARYWZHNtX3N1cHBvcnRAdm13YXJlLmNvbTAgFw0yNTExMjgxMDQwNTla
<--snip-->
GO10PoLXP5MZObWGarfkC/+IgY8=
-----END CERTIFICATE-----

After the deployment (running the command “python3 aria.py enable-blueprint-version-2“), the Aria Automation administrator will have to do the following:

1. Add users to Aria Automation, noting which namespace they have access to in DSM.
2. Assign these users the service role of Service Broker User
3. Create projects to match the project_to_namespace
4. Assign these users as member of their appropriate projects
5. Create new content sharing policies which grants the projects access to the DSM Content Source

1. Add users to Aria Automation with Service Broker User Role

In Aria Automation Identity and Access Management, assign the users the role of Service Broker User. This way, they will be able to trigger requests from the Service Broker DBaaS catalog item to provision databases from their own Project. If they have the role of Service Broker Admin, they would be able to see all projects, and would be able to request databases on namespaces which we do not want.  A Service Broker User role means that they only have access to their own project.

Note that there is no automatic correlation here between the DSM users and the Aria Automation users, other than the fact that, in this post, they are the same user in Active Directory (and both DSM and Aria automation support integration with AD). It is up to the Aria and DSM administrators to coordinate the correlation of the user in DSM and the user in Aria Automation to ensure that these users have access to the correct DSM resources.

2. Create Projects as per project_to_namespace in config.yaml

With the users configured, we can now login into Aria Automation as admin user, navigate to the Assembler and build the necessary projects that map to the config.yaml entries in project_to_namespace. With each project, assign one of the Service Broker users to the appropriate project:

It should look something like this. Of course, this is a simple example. If you have multiple users in a DSM namespace, these additional users would be added to the same project. To keep things simple, I am using a single user for each.

3. Create Content Sharing Policy Definitions

The final step for the administrator is to create new content sharing policies. These grant the projects access to the DSM Content Source so that they can ask DSM to provision databases. Navigate to the Service Broker, and under the Content & Policies tab, select Definitions (under Policies). In this example, I have created 3 policies, one per project. It should also be possible to create a single share and assign it to all projects.

And that completes the setup in Aria Automation. We can now go ahead and check if it possible to deploy a Postgres database as user dragomir from Aria Automation, and verify that it lands in the engineering-ns namespace in DSM.

Deploy a database via the Service Broker catalog

Begin by logging is to Aria Automation as the user ‘dragomir‘. As per the assigned role of Service Broker user, dragomir can only see the Service Broker service.

Clicking on the Service Broker, and then navigating to the Catalog, dragomir should only see a single item in the catalog, and that item should show that it is associated with only a single project, the ENG_DSM_PROJECT. So far, this looks like it is achieving our goal and ‘guard-railing’ the user dragomir into using the correct vSphere resources for data services, as defined by the Data Service Policy that is associated with the namespace where user dragomir resides on DSM.

Let’s validate this by making a request to provision a database. The only project available for selection in ENG_DSM_PROJECT, which is correct. Also, the list of available database versions matches those in the Data Service Policy to which the engineering-ns has been assigned in DSM. So far, so good. Continue with the deployment of the database.

Assuming that the deployment of the database is successful, dragomir can drill into the details of the database, and check which namespace was used for this deployment. And it does indeed look like that the deployment has been placed in the correct engineering-ns namespace as defined in the project_to_namespace directive in the config.yaml.

We can verify the same from the DSM Portal. Login as user dragomir, who we have seen has been added to the engineering-ns and check if the database is present. Since dragomir is a DSM user, a result of adding the DSMUsers-Engineering Directory Service Group in the Permissions section of DSM, he can access the UI.

Success. We have achieved our goal of integrating Aria Automation with the new RBAC features of DSM, and the relevant Data Service Policy controlling which users can provision which data services into which namespaces on DSM.