Separation of Roles: Developers and Deployers

[Naunghton]

Hi all, 

A question in regards to groups and access control in Dataiku DSS. So we are on Version 10 and I am looking to incorporate a layer of Governance as a short term solution that will allow me to allow Developers (Data Team) to develop bundles and publish them to the Deployer Node and another (Approver) which is allowed to deploy these bundles to different Automation Nodes. My goal is then that once a development team is happy with their changes, they can get it approved by an approver who then deploys it on their behalf. The reason for this is we want a stop gate to ensure that changes do not get promoted without approval.

I can see that I can restrict/Allocate Infrastructure to a group and that Admins are able to deploy on someone else's behalf. My question is, is there a security configuration that I can create to enable a user in a "Approver" role to deploy other people's bundles without just making them an "Admin".

Let me know what you think as the only way I have seen is by making the "Approver" an Admin or by making them the one who has to build the Bundle. 

[Naunghton]

Also, if this is something that can be controlled in version 11 then it would be amazing as well to know this. 

[fsergot · Accepted solution]

Hello @Naunghton ,

Natively, in Project Deployer, there are various level of security settings that would allow you to do what you are looking for.

In order to deploy a project, there are 3 potentially usable rights that needs to intersect:

1. The user must have the right 'Deploy' on the Infrastructure he/she wants to deploy to2. The user must have the right Deploy on the project

3. The user must exist and have sufficient rights on the Automation node.

In your case, option 1 could be put at use by granting only the right 'Deploy' on the infrastructure the group 'approver' and not to 'developer' (who will only have the 'View' rights).

Developers will still need to add the approver groups/people to the project settings otherwise, they won't be able to deploy (this is something we will to simplify in a future release by propagating rights from the Design project)

Govern in version 11 add the notion of 'pure' Approver for bundle, meaning one or several persons or groups that will need to give their go before anyone can deploy this bundle. This is stronger than the solution presented here and does not require specific rights in Project Deployer Infrastructure or project so is easier to implement. You can check more on documentation: Governance » Sign-off Scenario 

[Naunghton]

Hi @fsergot,

Thanks for this! What version of Dataiku are you running on to get these options for separating who can deploy a project?

From my view (Version 10.0.2) we are only able to see the following permissions and I have found that only by giving a group admin over a project will give them the permissions needed to deploy.

Let me know what you think! 

[Naunghton]

Or is it the case that we should deploy bundle to deployer, then assign the "approver group" permissions to deploy that project specifically and then the approver would be able to deploy to the infrastructure that they have permissions to?

[fsergot]

Indeed, those are rights that are in Project Deployer, not in the original project.

[catten92]

Hey fsergot, 

Thank you for the explanation. I have a question to your second image. The permissions on the deployer node for a project. Is it possible to configure that certain groups have "Deploy" permission and not only the admin group?

I have a so-called "writer" group on the design node project level, which has all  the permission EXCEPT the admin permission. That person can develop, and create a bundle, but not deploy it so far, except the owner or the admin changed it manually for each project on the deployer node (This is what I want to avoid).

Do you have any idea if this is not possible with Dataiku 12?

best regards,

Christophe

[fsergot]

Hello @catten92 ,

I am not 100% sure of your use case. What I can say is that deploy right can be granted to any group indeed. In the case below, the group called mlops has the right to deploy (and this is a custom group).

Regarding your particular project, you can set your WRITER group to have deploy rights on the project in the Deployer manually.

And one point, which might your issue, is that we propagate permissions from the Design node to the deployer. However, this propagation does not grant the 'Deploy' right to any group of users that is not Admin on the original project. This was done for "common security" practices as Deploy is usually seen as an elevated right compared to read/write.

So, as of today, if you want to grant deploy rights to an additional group, a user with admin permission has to do it manually. There is no built-in workaround that unfortunately for now, you can still do this change as part of a deployment macro or a scenario using APIs though.

(as a last note, permission propagations has changed quite a lot in the last versions, so this might be dependent on the exact version you are using)