I suggest you...

Permission attributes for variable sets, library variable sets, or even variable

Add RO attribute/flag to variable set to prevent accidentally changes of it. Or even develop extended permissions linked to username, groups etc. For example in our Octopus environment we have default variable set in library for special package and I'm afraid if somebody will change it accidentally and it will affect to whole related projects where it will be used

446 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Alexey Pogosov shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Pooja commented  ·   ·  Flag as inappropriate

    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.

  • MauroCam commented  ·   ·  Flag as inappropriate

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

  • Dan Carlstedt commented  ·   ·  Flag as inappropriate

    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).

  • Kelly Campbell commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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.

  • Jan Skalicky commented  ·   ·  Flag as inappropriate

    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).

  • Jan Skalicky commented  ·   ·  Flag as inappropriate

    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.

  • Mark Boyle commented  ·   ·  Flag as inappropriate

    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 :(

  • Sean Killeen commented  ·   ·  Flag as inappropriate

    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!

  • Matt Ford commented  ·   ·  Flag as inappropriate

    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 :(

  • Peter Bollwerk commented  ·   ·  Flag as inappropriate

    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.

  • JonG commented  ·   ·  Flag as inappropriate

    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.

  • Andy commented  ·   ·  Flag as inappropriate

    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.

  • Jake Kerber commented  ·   ·  Flag as inappropriate

    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.

  • Andrew commented  ·   ·  Flag as inappropriate

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

  • Gelhaus, Chris commented  ·   ·  Flag as inappropriate

    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.

← Previous 1

Feedback and Knowledge Base