Permissions seem a bit of a mess

Legacy Uncategorised
1

Hello,

While, yes, I do use the word “mess” here, I mean that in a more confusing sense. Here’s what I’ve noticed:

  • Trying to provide access fine grained control to things in the configuration menu is impossible. For example, unable to get to the audit log without granting AdministerSystem
  • I have given a custom role the VariableView permission only to be told I don’t have it when I go to view a particular variable set. All I can see is the list of sets.
  • More broadly, I am unable to give a targeted permission to a role in any meaningful way without, in many cases, also giving it many other interstitial permissions that I don’t necessarily want

Mind you, I’m coming from a very audit-heavy environment. Tightly scoping particular actions is greatly desired. I’ve tried several “view only” attempts only to be told either I don’t have the permission or that I needed another permission in order to get to the point where the view permission has any meaning. I don’t know if these are API limitations or limitations of the web portal that comes with Octopus, but it’s quite frustrating from a security and regulatory standpoint.

I marked this as a question as I’d really like feedback if I’m missing something “obvious,” but would also like this to stand as general feedback.

Thanks.

2

Hi Michael,

Thanks for getting in touch. Also thanks for the brief explanation about the use of the “mess” word :).

I feel like the most productive way we can carry on with this conversation would be to explain point by point your permission queries. This means I’ll answer the 3 you made in your initial post, and that I’m also opening the doors for you to ask about more examples of permission setups you’d like to achieve.

Trying to provide access fine grained control to things in the configuration menu is impossible. For example, unable to get to the audit log without granting AdministerSystem

All the options under Configuration are meant to be for Administrator eyes only. So this is as design at the moment. What kind of information would you like a non-admin to be able to see in the Audit menu for example? We’ve been talking about adding extra granularity to the visibility of the Audit window by perhaps not making it exclusive to admins, and comments like yours might help us getting in the right direction.

I have given a custom role the VariableView permission only to be told I don’t have it when I go to view a particular variable set. All I can see is the list of sets.

The role VariableView aims to give permissions over Project’s variable sets. These ones you see when you go to Projects->[Project name]-> Variables. Variable Sets on the other hand are the ones shared by all projects in the instance, and you can find them under Library -> Variable sets. The latter ones have their own set of roles which are called LibraryVariableSet*.

More broadly, I am unable to give a targeted permission to a role in any meaningful way without, in many cases, also giving it many other interstitial permissions that I don’t necessarily want

If you can give us more specific examples about this, we can give you a hand explaining the reason behind these permission rules.

Best regards,
Dalmiro

3

Dalmiro,

Thanks for the response. To give some more clarity into the rough organization structure I’m trying to represent, my concerns are roughly divided like so:

  • Development team members
  • Infrastructure management
  • Production support
  • Compliance enforcement

Not all of the people involved in these roles are necessarily in IT. In particular, production support and compliance are split across my org in a few different ways. So, letting them see things like an audit log - or really to view anything - is a potential need which they can request at any time but they mostly certainly have no business messing with SMTP configuration and so on. By design we even have a few IT staff members who are intentionally separated from development and are user advocates for the business. They also have no business affecting configuration. Further, there are the graduations between junior and senior members. We don’t really want to give junior folks the ability to mess with global Variable Sets. If they need to tweak something for a particular project, that’s fine. Otherwise, they should seek help from a more senior member of the team. All that said, they should absolutely be able to see the values so they can code appropriately.

At a glance, Octopus gives all this out of the box. As to VariableView, noted. As for specific examples, here are some:

  1. I have a user setup with the built-in and unmodified Project viewer role as part of a Reviewers team which has no environment or project scopes defined so it should be able to see all projects and all environments. It claims to:

Project viewers have read-only access to a project. They can see a project in their dashboard, view releases and deployments. Restrict this role by project to limit it to a subset of projects, and restrict it by environment to limit which environments they can view deployments to.

However, going to a project and clicking releases I see nothing. (See attached) In order to view a release, I can only go through the dashboard.

  1. Similarly, still on the VariableView permission, I have given the same Reviewers team that permission only to be told I actually needed the ProcessView permission. (See attached)

  2. As a separate point, some permissions seemingly get lumped together. Viewing the processing implies you can add a step even though you do get an error about needed the FeedView permission. Similarly, apparently having access the Library tab at all gives you access to see script modules. On that Reviewers team, on none of its roles have I told it that I want to see that but it’s given anyway. Similarly, simply having FeedView apparently means I can add external feeds even though it is a “view” permission. I don’t want just anyone being able to bring in outside packages just because they can test to make sure the packages they need are available to Octopus. The AdministerSystem permission is apparently required to actually add them which is confusing why that action was lumped with that permission.

So, in summary, I can’t help but get the notion that your permissions are not accurately named or described. I feel like you should take some effort and reassess them holistically and either combine some or separate others. However, they absolutely need some review a touching up.

octopus_project_viewer.png
octopus_project_viewer.png1045×950 26.6 KB

octopus_process_view.png
octopus_process_view.png1045×950 29.8 KB

4

Hi Michael,

Sorry for the delay here. The reason behind it is that I wanted to ask around the team for a few opinions about some of the points you brought up. I’m gonna answer them 1 by 1:

Query about segregating permissions for the Audit log

This is something that has been discussed before in the team, and we even have a Github issue created to implement this enhancement. We haven’t started to work on it, but we will do it eventually (probably after we ship 3.4). You can track its progress on this link: https://github.com/OctopusDeploy/Issues/issues/2526

1) going to a project and clicking releases I see nothing. (See attached) In order to view a release, I can only go through the dashboard.

The Dashboard shows the releases, deployments and their status. When the users tries to see the same info from the Project Overview page (/app#/projects/[Project Name]), even though that seems as if it was the same info as in the dashboard, it also shows the Channel for which that release was created. So to be able to see info in the Overview page, the user needs to be able to see the channels as well. We don’t have segragated permissions for channels and they are bundled along with ProcessView

2) Similarly, still on the VariableView permission, I have given the same Reviewers team that permission only to be told I actually needed the ProcessView permission. (See attached)

Variables can be scoped to Machines, Environments, Roles, Channels and Steps. For the user to be able to see the steps, it needs ProcessView. Hence this error message.

Viewing the processing implies you can add a step even though you do get an error about needed the FeedView permission. Similarly, apparently having access the Library tab at all gives you access to see script modules. On that Reviewers team, on none of its roles have I told it that I want to see that but it’s given anyway. Similarly, simply having FeedView apparently means I can add external feeds even though it is a “view” permission. I don’t want just anyone being able to bring in outside packages just because they can test to make sure the packages they need are available to Octopus. The AdministerSystem permission is apparently required to actually add them which is confusing why that action was lumped with that permission.

I’ve discussed this with our UI/UX person and she took note of it to improve the overall experience in these cases. While I definitely share your thoughts on “why showing a button if you don’t actually have permissions for it?”, I was also once learning about Octopus and messages such as “You are missing X permission” were really helpful to get the grasp of which permissions I actually needed. Right now we do have some different behaviors depending on the page you are standing, and we are currently working on choosing 1 path/set of rules and going forward with it on the entire site.

Best regards,
Dalmiro