We have configured separation of duties within Octopus so that non-privileged users are not allowed to deploy to production. We’ve also scoped away standard permissions for non-privileged users so that production deployments can only be started and managed by certain privileged users whom must authenticate to Octopus using special Active Directory accounts. This separation of duty only seems to be partially working. Not only did the UI allow button access to something it should not have, but the backend allowed the action to pass through.
Example showing that my non-privileged user cannot deploy to Production (this is working)
Now if I utilize my privileged user to start the Production deployment, the progress becomes visible to my non-privileged user (this is working)
Once my non-privileged user accesses the Production deployment, I seem to have the ability to take control of manual interventions and even cancel the deployment (not working as expected)
Here are the effective settings for Intervention and Task management for my non-privileged user.
Production is listed nowhere in the allowable scope yet I just canceled that deployment. This is bad!
Octopus version v2020.5.1
Thanks for getting in touch! I’m sorry for the confusing behavior you’re experiencing here. My first thought was perhaps the user is unexpectedly granted this permission by being in a team that has the
TaskCancel permissions, both being unscoped.
I attempted to reproduce this issue, though with no luck in doing so. It’s possible I’m not doing so exactly as you have configured, so the best information to do so would be to get a permissions export from this specific user. You can grab this in the UI under
Configuration > Test Permissions, selecting the user (same page as your screenshot) and clicking the
Export button. Feel free to mark this thread as private, or email it to firstname.lastname@example.org and I can grab it there.
I look forward to hearing back!
The Test User Permissions is exactly where I got the above settings.
Thanks for following up, and my apologies. I was meaning to ask specifically if you’d be willing to send through the actual full user’s permissions export file that is generated when you click the Export button on that page. That’ll show us a full list of all their permissions and how they’re scoped for this user in which I can use to replicate your setup exactly.
I had time to dig deeper and I may have spotted where permissions are leaking in from another role that we had set up for runbook permissions. Let me take a day to see if I can prevent the behavior that I described above, by modifying this role that I spotted. Correct me if I’m wrong but some of the permissions for runbooks are shared with permissions for deployments, such as TaskCancel and InterruptionSubmit? If that is correct then that is probably what is going on here.
Thanks for the update, and that sounds promising. That’s right, those permissions would apply for both deployment processes and runbooks.
Let me know how you go!
So yes, after excluding Production from the Runbook role that leaked the permissions, the issue I saw does seem to be patched. The problem now is that Runbook permissions are affected. Since Runbooks and Deployments share certain permissions, is there any guidance as to how we should structure our teams and roles so that we can have a separation of duty for production deployments, but also allow Runbook executions in Production for regular users? It really seems that this issue is complicated by the sharing of permissions.
Also a suggestion, in the Test Permissions UI, it would be super helpful if the role was notated there or if each instance was clearly marked. That would make spotting these “leaking” permissions so much easier. As it stands, the UI is not very intuitive. For example TaskCancel having blank rows indicates unscoped inheritance from other roles but to an untrained eye, it stands out as nothing.
Thanks for all the help Kenny, this one appears to be on me and not really a defect directly.
Thanks for following up, and that’s great to hear you’ve found the solution here. I get what you mean, and I can see potential for a change to improve this area. Troubleshooting permissions is a bit hairy in situations like this, so your idea to notate the role in the Test Permissions is a cool one. I’ll raise this internally, but there might be a specific reason it isn’t done this way that I’m unaware of.
You can split out these permissions by adding/modifying runbook-specific permissions (RunbookRunView, RunbookRunCreate, etc.) which should hopefully give you the control you’re after by giving them different scopes as compared to the separate deployment-specific permissions.
I hope this helps, and please let us know if you have any further questions or concerns.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.