I am facing issue while giving permission to users to edit the Variable set only for non production environments. Either it is giving permission to edit the variables belonging to all environments or its giving only view permission to all environments.

Is there any update on this request? We want to store sensitive variables and only allow access to them by specific project teams.

I would like to stop bugging my web team to update variables in my project level variable set. This is required because we have a global variable set that has our core project variables and if they give me permissions to update then I would also have permission to the global variable set (which only our web team should have permission to change per our process).

I am running into this issue, where we want to have different permissions on different variable sets. It would be helpful if Teams could be given permissions on specific variable sets.

Maybe also something that prevents reusing passwords between Octopus Deploy and other web sites

We have the same issue as Mark, we don't use project level scoping at all, only environment scoping. As it currently stands people who shouldn't see production scoped variables can see them if they are in a variable set. This behaviour has changed somewhere between 3.5.2 and 3.17.8 since we defined and tested our access model and had it signed off by our internal auditors, now this breaking our access design.

I would like to add my voice to this request.

What is the status of this? This is a fundamental feature.

Or create some other entity (e.g.: "Space" ) to which everything will be scoped. We want to have one Octopus instance for different teams and at this time there is couple of things we fight with.

This is our scenario:
We want to have one team which will take care of upgrading Octopus and all needed administration.
We have multiple teams. Each one wants to have unlimited access to their environments, accounts, tenants, lifecycles, project groups, "sub teams" and "sub roles", variable sets and action templates (these should be common and specific).

Please scope variable set to project group or project. Everyone with permissions:
to project group + to edit variables + edit variables sets
will be able to work with that variable set.

Shouldn't it be pretty easy to at least add a set of variable sets to a team?

It looks like we won't be allowed to use variable sets in my company because dev/qa team members would be able to edit variables that are scoped to the production environment. Apart from being a bad idea, our security auditors would never allow this :(

Ran into this just now on a client site and it's a bit unfortunate. I am maintaining 2-3 projects within OctopusDeploy for them, and those projects should be sharing variables with set. However, because I am restricted to these projects, I cannot view variable sets -- even those which I've just created that are empty. They either have to give me more access than they might be comfortable with, or I have to duplicate all the variables.

As such, bumping this up in the hopes that it can be resolved sooner. Thanks for considering!

Just ran into this one now and it is quite annoying. Project Team will have the ability to change the Library Variables which could affect every project we do, just so they can have the ability to edit their own Project Variables.

Out of votes too :(

I would like to add my voice to this request.
We have the same issue as Andy.
We are forced to allow a team to have inappropriate access to Projects they aren't involved with, just to be able to edit a Variable Set.
Please add the ability to scope a team to specific Variable Sets, as you currently do for Environments and Projects.

Need ability to give teams permissions to edit the Library Variable Set used in their own environments without being able to view/edit variables in other Library Variable Sets.

Possible solution is to add Scoping to variable sets as well as respecting scoping on individual variables within the variable sets.

Add: Scoped and Unscoped Library Variable View/Edit permissions.
Add: Scoped and Unscoped Library Variable Set View/Edit permissions.

We would also greatly benefit from the ability to scope Variable Sets to specific projects. The alternative is to over overly permissive Team roles to our developers which increases the surface area for a security breach.

It would be great if a variable set could be associated to a project or set of projects. This could work (from a UI perspective) similar to how Teams are associated to projects. If no projects are specified, they apply to all projects. This would then provide a way to help control security for the different variable sets across an organization. If you have access to variables for a particular project, then you have the same access to the variable set(s) that are associated to that project.

I agree with Chris Gelhaus, we are faced with the same issue as his org.

I'd like to have the ability to assign permissions to individual variable sets. We wanted to isolate our database connection string information so we've given our DBA team access to the variable sets; however, this means we've had to lock everyone else out of using variable sets.