Roles and viewing variable sets (have VariableView but can't view variables)

Legacy Uncategorised
1

I’m trying to configure security with our Octopus setup.
I want to setup teams that can see and edit variables of their projects (in various environments).

I created a Role that includes LibraryVariableSetCreate/Delete/Edit/View and also VariableEdit, VariableEditUnscoped, VariableView, and VariableViewUnscoped (among others).

I setup a Team that has that role for all projects for all Pre-Production environments. I also created a Team that has that role for all projects for the Production environment.

I added myself to both of those teams. I then removed myself from the Octopus Administrators team (there are others in my organization that can add me back in).

I expected to be able to view and edit the variables in the Library Variable Sets. But I can’t.

I can see the list of Variable Sets, but when I click on one of them, I get "You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: VariableView"
I can even create a new Variable Set, but then it immediately gives me the error message.

If I use the “Test Permissions” feature on myself, it shows that I have VariableView for all projects for all pre-prod environments, and VariableView for all projects for the Production environment (on 2 separate lines in the table).

We’re on version 2.6.4.951.

2

Hi Jake,

Thanks for getting in touch! Sorry for the delay in getting back to you.
Your permissions sound like they are behaving. Because you can see the list of library sets you have the library variable set permissions, but because you get that error when you click through this will be related to scoped variables inside the Library variable set. These are slightly different to project variables. I am thinking there will be a scoped var or two that you do not have access too for a specific environment or project. The error message can’t really be more specific about which variable.

Vanessa

3

But it won’t even let me see an empty variable set - with no variables in it at all.

4

Plus, according to the roles and teams assigned, I should have access to all projects in all environments (production via one team and pre-production via the other team). No?

5

Not sure if you saw my responses on the support site, so I’ll duplicate here…

But it won’t even let me see an empty variable set - with no variables in it at all.
Plus, according to the roles and teams assigned, I should have access to all projects in all environments (production via one team and pre-production via the other team). No?

6

Hi Jake,

So like I said, currently if you do not have the correct permissions for ANY of the variables inside a set, you can’t see the set. The fact that you can see the list shows you have the correct permissions to see variable sets. We are going to look into why this is and fix it (but it won’t be til 3.0). Here is an issue you can track: https://github.com/OctopusDeploy/Issues/issues/1569
The only work around will be to have permissions added for the variable that you aren’t scoped to see.

Vanessa

7

Hi Vanessa, Thanks for the response.
After some further investigation, I figured out what’s going on.
The root of the problem is that Variable Sets aren’t associated with projects.

We have a group of around 20-30 developers who work on related projects. We currently have 13 Projects defined in Octopus within 6 different Project Groups. They all share a common set of variables (in addition to project-specific variables).

We want other developers in our organization to use Octopus. We want our users restricted to administering just our own set of 13 projects (and other developers only administering their own projects). When we defined our Team in Octopus we specified the set of 13 projects (all of them currently defined). But since the Variable Set doesn’t specify which projects the variables in the set could pertain to (and thus could pertain to a potential project outside that set of 13), it didn’t allow access.

As an experiment, I removed the project restriction from the Team, so the Team could see all projects. I also created a Variable set with a Production variable, a pre-production variable, and an un-scoped variable. Then my user was able to see the list of variables in the set – including just the variables for the proper environments. He could see the non-production variable and the un-scoped variable, but the production one was hidden – just as I would have expected given the Role and Team definitions.

So our only options seem to be: don’t use variable sets; or allow all users who can configure Octopus projects to be able to configure all projects across our organization.

It would be great if either:

  1.  We could specify, for each variable set, which projects it applies to, or

  2.  Octopus would use the “Included Variable Set” functionality for each project to identify which projects the Variable Set applies to – for determining Variable Set permissions.
8

Hi Jake,

Variable sets are supposed to be global and re-usable. Defining it for a single project would be no different from defining project variables.
There is a possibility that we might consider adding something such as limiting variable sets to Teams where only people in the team can see and use their own variable sets. And the team could be limited to projects or project groups. We would probably have to see this in UserVoice to really get an idea of how many people need it as generally the devops assigned at admin level are the ones managing these variables that they don’t want project specific users to change.

Vanessa

9

Hi

We are using Octopus Deploy in an enterprise environment, and it would be very useful if individual groups could be assigned access to specific variable sets. Octopus lacks the more hierarchical approach to access management that can be found in, say, Teamcity. But the only place where there really is no workaround is the ability to define specific users access to specific variable sets. The use case is groups of projects owned by specific business units where some configuration is shared inside the business unit but should not be visible to other departments.

KR Morten

10

Morten,

Thanks for the feedback. We will certainly consider this.

There is a suggestion for this on our UserVoice site. I encourage you to vote for it.

Regards,
Michael

11

Unfortunately, that link is broken (it just takes you to the home page of the Octopus documentation).

Here is the correct link to the suggestion on UserVoice: