Strict Mode - Open Discussion

1

Sorry, accidentally deleted my last post:

Just thought I’d post here as I’ve been trying to get my instance configured with the ‘Strict’ security model for some time, unfortunately there’s been a few issues I’ve been waiting on resolution which now seem to all be good since the release of 5.6.8.

Let me preface by saying, previous orgs I’ve been part of a dedicated automation team, owned the solution and typically only the people in our team had access to it and there was no need for any granularity or ‘roles’ it was just if you had access and wanted to develop on the platform you had full admin access.

My current org, things are different, I’ve introduced this platform, but there’s no dedicated team to own automations, and instead i’ll be looking to bring other teams into the fold.

The challenge here is security.

Different automations and integrations have access to different things, and not everyone should see everything.

Most of that is addressed with the new ‘Strict’ mode in v5, being able to set role based permissions at the script level and various components of the admin menu is a HUGE improvement, as well as on apps and the portal etc.

However, I’m struggling with the following:

  • Schedules

  • Triggers

  • PSU internal commands

  • Running jobs on different nodes (this one is particularly frustrating as I have a web node and job node so my users will be coming into ServerA admin portal, but always running jobs against ServerB, all jobs with any PSU commands will fail due to this, even if the user has the correct permissions. If i test against server A they work fine).

For the first two, they do not inherit any sort of permissions so if you set a role on a variable, it can’t access it and internal PSU cmds do not work, things like Get-PSUJob or Invoke-PSUScript, which I use frequently.

Couple of examples that stopped working when I switched to Strict mode:

  • A job that runs on a trigger (failure of any script) and calls get-PSUJob (because there’s missing metadata in $job), it then creates and sends an email notification to relevant users of that automation.

  • Any Schedules that run scripts where the script completes, but the last step is to Invoke-PSUScript on another script directly after.

  • I tried to change the above instead to a Trigger method, but triggers cannot have paramters it seems and they also dont fire when configured on the job completion of a specific script (open bug for this).

  • Pass through authentication, if I choose “Run job on all nodes” and that job has any PSU commands, it only works on the current node, presumably because it’s not handing my permissions/authentication to the second node

Typically the failures above just throw the standard gRPC errors you see when there’s some sort of permission problem.

Other discussions I’ve seen on this involved people putting a PSU token into a non secret variable so it can be accessed by the schedule, though this sort of defeats the purpose of strict mode in the first place and anyone can get access to that variable since it wouldnt have roles either.

I wanted to reach out to all of you and understand how everyone else is using or configuring their instances in strict mode?

2

Not sure where to go with this to be honest, @adam is there anything on the roadmap on how schedules and triggers can access secrets (that are also secure to specific roles)? or am I just going about this all wrong with my use cases?

3

image

Having secrets with no roles means that I can use them in scheduled scripts, but it also means that anyone with access to PSU can see/use those secrets if they were for example accidently put into a dashboard page, or into a role restricted script thats being executed by the user.

I think it poses an issue about governance, since I could open up my PSU instance to other developers in other teams, but they might include public secrets in automations for users that really shouldnt have the ability to use them.

In an ideal world, each team that develops within PSU would be restricted to a dedicated keyvault, or role that has only the access for specific secrets and nothing else. Currently it means I’ve forced to make most things ‘public’ because schedules cant use roles, so I can’t lock things down how i’d like.

For me I think the solution here would be to remove code defined schedules/triggers, and have database defined only, but enable roles to be added to those schedules/triggers (providing the creating user has privileges to do so), that way they could access role restricted secrets when executing. Or having the schedules/triggers inherit the roles/context of the creating user.

I’m just floating my idea because I’ve got no other solution at this point, unless there’s a better method, or something on the roadmap with RBAC now devolutions is in the picture?

Or am I just looking at this all wrong or trying to use it in the wrong way? @adam - Any thoughts on this one?

4

Sorry to keep bumping this, but this is a really key/critical piece of this product for me and the only thing that is unsolved making me consider it truly enterprise grade and enabling other teams to get involved.

Again - I might be looking at this all wrong, but the way I see it currently is that RBAC on secrets in strict mode is pointless so long as we can’t provide RBAC to schedules and triggers also. (unless you don’t use schedules and triggers and only use manually run jobs - in which case you can RBAC the secrets to your hearts content). Instead all the secrets that are needed for schedules and triggers are essentially open to anyone and cannot be restricted by roles.

I’m hoping someone can just tell me I’ve got the wrong end of the stick here.

@adam - even if it’s a long way off, it would be good to get an understanding on direction, am I going about this wrong? am I missing something? or is there a future plan for improving RBAC on secrets for things like schedules and triggers?