How Can I Safely Add a New Developer to My Workspace Without Exposing Sensitive Data and Workflows?

1

This topic was automatically generated from Slack. You can find the original thread here.

Hello, I would like to invite a developer to my workspace, however there are many sensitive env variables and workflows that are crucial to my business; How can I:
• Restrict permissions to not affect existing flows
• Ensure my env variables remain secure
• Allow the new developer to work on new workflows without exposing my current space to excess risk
Currently I’ve created a separate workspace to build the integrations, but this is cumbersome as the free tier does not have acccess to premium features such as Pipedrive.

Any suggestions would be great.

2

We are very close to shipping the first version of RBAC / access controls! It will provide private apps auth provisions and future iterations may include env vars, projects/workflows, etc.

3

Great questions, Darren! Like Andrew mentioned, we’re very close to rolling out the first iteration of RBAC, which will let you manage permissions for your connected accounts. They’ll be private to you only, by default, and you can then choose who within your workspace should be able to use it in a workflow.

4

Can you tell me more about how you’d like to restrict permissions to workflows? What did you have in mind there?

5

And it sounds like similarly, you’d like to manage access to env vars as well? Can you tell me about how you use env vars today?

6

Thanks for the response. It sounds like RBAC would be what I’m looking for.

I’m a Founder / Director, so forgive my novice approach, but I’ll try to explain my use case:

• I’ll hire a developer (untrusted) from upwork, fiverr, replit etc
• I would like to define granular permissions so that they are able to work with env variables specific to their task IE lowest permissions possible
• Zapier is a good example, It has a “folder” with shared zaps for the member to work with limited scope
I’m currently working with a dev to move a number of Zaps from Zapier to pipedream and then deprecating the Zapier subscription in favour of pipedream. However I don’t want the new member to have access to sensitive env variables or workflows which could expose clients personal information from our main databases.

Thanks again for your response

7

Got it, makes total sense. The current scope of what we’ll be shipping soon will not solve your problem yet, but the next phase we’re discussing likely will. We’re just now starting to roll out Projects in Pipedream, which you can use to group workflows (and eventually other resources like connected accounts, sources, Data Stores, and env vars) together, and we’re starting to look at managing access at the project level.

So in your example, you’d be able to add a new developer to a specific project that you have in Pipedream, and they’d only have access to what’s contained in that project.

8

That would be exactly what I would need

9

What approach are users taking now in this situation?

10

To work around that now, some users will use separate workspaces to handle access management

11

Which is not ideal because if you need to upgrade to a paid plan, the plan is linked to a single workspace

12

yep, that’s what I’ve currently done.

13

I read in the documentation that support can help to migrate workflows to the main space, is this something you can assist with?

14

I have around 10 flows in such a workspace, I would like to invite the dev to the main space and migrate these in

15

So you want to move workflows from one workspace to a different one?

16

Yes. The temporary space => main space

17

I believe support can help facilitate — the disclaimer is that the migration process will move all resources from workspace A into workspace B, and I believe it overrides whatever is there. All resources means connected accounts, sources, workflows, data stores, etc.

18

ohhhh

19

ok, i might just use the share link and bring them in one by one

20

Yea that’d be the suggested workaround