Change Project Variables ONLY Permission for APPs without Allowing Changes to the rest of the flow.

csmith294

In discussion with customer support, I was told that:“Only instance administrators can change the run as user. So while a user can create an instance of an application and technically modify the flow, it will still run under their credentials.”

In practice, we’ve seen a different pattern emerge. Developers often create app instances on behalf of users and then grant those users permission to modify the app (typically so they can adjust variables).

The issue is that once those edit permissions are granted, the end user effectively has the ability to modify the flow, and the changed version still runs under the developer’s “run as” credentials. This creates a security concern, as it opens the door for unintended or unauthorized use of those elevated permissions.

I have personally used this behavior to gain unauthorized access to datasets that I was not properly permissioned to use.

This a security risk that I'd like Dataiku to address by allowing the use of apps and the ability to change variables without allowing end users to modify the rest of the flow.

csmith294

This idea may already have been added to the backlog log as I have been in communication with customer support. Adding here for tracking purposes and to receive upvotes from the wider community.

Please note. This is a feature request. I'm not suggesting there is an issue, I would simply like to change how it currently behaves.

I’ve trained 2,000+ users on the platform over the past few years. I’m very familiar with how “run as” permissions and Visual Apps work today.

The idea here is to make Dataiku apps behave a bit more like Alteryx Apps, especially as my team supports a lot of Alteryx → Dataiku migrations.

The main issue: we want to let end users run processes using a developer’s “run as” permissions, but can’t safely do that today because apps are still editable. If there were a way to lock down editing (while still allowing things like project variables), we could use this feature much more confidently.

Example: A process owner (John) builds a report pulling from Oracle that 100+ users rely on. Ideally, users could run it using John’s credentials without needing direct access to the data. This works in Alteryx because apps are locked down—but in Dataiku, the current options are:

• Give everyone access to the source data (not ideal), or
• Share the app with “run as,” which introduces security concerns since it can be edited by end users.

Solving this would make a big difference for us and our shared clients.

Turribeach

I think the issue is that you are granting edit permissions to the app where you shouldn't. You could easily move your variables to another project which users can edit and leave the app instance without permissions. And pretty much any specific security workflow you may have can be implemented with a custom Dataiku webapp which can run under an admin account and enforce whatever custom rules you may have.

csmith294

https://community.dataiku.com/discussion/comment/47282#Comment_47282

You suggested that variables could be moved to another project where users have edit access, while keeping the application instance itself restricted and enabling RUN AS DEVELOPER Permissions.

Could you elaborate on how this would work in practice? We’ve explored several approaches along these lines, but each has been blocked for different reasons.

You’re correct that what we’re trying to achieve is technically possible using a custom Dataiku Webapp. However, that approach requires a level of coding expertise that our target user base does not have. I'm trying to train 500+ business users.

That gap is exactly why we’re requesting this feature. While similar functionality exists elsewhere, we’d like to see it made more accessible within Visual Applications, so non-technical users can achieve the same outcomes more easily.

Turribeach

"We’ve explored several approaches along these lines, but each has been blocked for different reasons." ⇒ explain your different aproaches and why they don't work.

"However, that approach requires a level of coding expertise that our target user base does not have." ⇒ The webapp can be generic and provided by you for all users to use.