How do we set up a team which can view / edit variables of one specific environment and all global variables that are non-environment specific?

Hi,

We have 4 environments set up in Octopus 2 - DEV, SIT, UAT and PROD. We would like to create a team called “Developers” which can only view and edit all DEV variables and all non-environment specific (ie global) variables.

How do we configure this? The non-environment specific option is not available for creating teams in Octopus 2.

If we don’t set any environments for the “Developers” team, then this team will be able to view and edit all variables including the ones for SIT, UAT and PROD, but this is not what we want.

Please advise, thanks.

Hi,

The global scope applies to all environments unless an environment-specific variable is defined. If we allowed users to define variables for global scope when they don’t have access to edit production variables, then they could sneakily override certain variables in Octopus to force things to run or set variables that override production variables.

Variables in 2.0 can be scoped to more than one environment however, so it’s possible to create a variable and make it apply to DEV, UAT and SIT without creating duplicates.

Hope that helps,

Paul

Hi Paul,

Thanks for the reply.

Yes we have noticed that we can create variables that apply to multiple environments (eg: for us, it’s DEV, SIT, UAT and PROD). However unfortunately only users who have permissions to access all target environments are able to view / create / edit these variables. For users who have (for example) only the DEV permissions (eg developers), they can only view / edit / create variables for the DEV environment.

In Octopus 1.6, we were able to configure, for example DEV users to view / define / edit DEV specific variables and non-environment-specific variables. And this makes sense for us, as developers can set up variable mappings such as:

Name: VariableA - Value: NetworkShareLocation - Scope: no scope
Name: VariableB - Value: #{VariableA}\DevDropFolder - Scope: DEV

In our projects, almost 2/3 of the variables are non-environment-specific (they may bind to other scopes eg: step-specific or machine-specific), only 1/3 of them are environment-specific.

Without the ability to view / edit / define non-environment-specific variables, users in environment-specific teams are no longer able to manage variables that are binding to other scopes (eg: step-specific or machine-specific) and they can’t set up the corresponding variable mappings, unless we gain them permission to access all environments which is more than what is required. This is a catch-22…you either have no access or too much access…

To address this problem, we think adding an option to “Include non-environment-specific settings” (eg: variables) in Teams would help. Is it possible to add this feature?

Thanks.

Thanks for the feedback and explaining your scenario more. I’ve created an issue here to track it and we’ll find some way to support this in a future release:

Paul

Hi Paul,

Thanks a lot for the help and understanding. Do you have a rough idea of when this feature will be available? There are lots of cool features in Octopus 2, however this problem creates a big concern and it is now blocking us from moving on.

Thanks.

Hi,

We’re planning to include it in a pre-release build that will be available on Monday 31st March.

Paul

Hi Paul,

Awesome! Thanks a lot for the prompt response. We look forward to seeing this new feature in the new build.

Thanks for the help again.

Hi Paul,

We’ve downloaded pre-release build 2.3.4, and it doesn’t seem to have the feature that we want. Do you have a rough idea of when the feature will be ready?

Thanks.

Hi Canny,

We discussed this and again hit potential security holes that would be very surprising if we implement this.

Essentially, if we implement this feature, then users with this permission would have administrative access to all environments anyway, so giving that permission explicitly would have the same effect.

We’ll add some more details on the ticket and see if there’s any other option we’re missing here; sorry about the inconvenience.

Nick

Hi Nick and Paul,

Thanks for the reply. This feature is very important to us, without it we can’t really use Octopus v2.

We have Developers, Testers, Supports and DevOps. ‘Developers’ is the owner of the DEV environment, ‘Testers’ is the owner of the SIT environment, and ‘Supports’ is the owner of the UAT and PROD environments. ‘DevOps’ is the Octopus Admin, it doesn’t own any environments, and it doesn’t set up any projects.

In our projects, people in each group are responsible to configure deployments for their own environments. So for example in Octopus v1.6, we have these variables set up in a project:

  1. Name: ServiceName, Value: ServiceA, Environment: non-scoped, Step: 1.ServiceA

  2. Name: ServiceName, Value: ServiceB, Environment: non-scoped, Step: 2.ServiceB

  3. Name: ServiceName, Value: ServiceC, Environment: non-scoped, Step: 3.ServiceC

  4. Name: ServiceUserName, Value: DEVusernameA, Environment: DEV, Step: 1.ServiceA

  5. Name: ServiceUserName, Value: DEVusernameB, Environment: DEV, Step: 2.ServiceB

  6. Name: ServiceUserName, Value: DEVusernameC, Environment: DEV, Step: 3.ServiceC

  7. Name: ServiceUserName, Value: SITusernameA, Environment: SIT, Step: 1.ServiceA

  8. Name: ServiceUserName, Value: SITusernameB, Environment: SIT, Step: 2.ServiceB

  9. Name: ServiceUserName, Value: SITusernameC, Environment: SIT, Step: 3.ServiceC

  10. Name: ServiceUserName, Value: UATusernameA, Environment: UAT, Step: 1.ServiceA

  11. Name: ServiceUserName, Value: UATusernameB, Environment: UAT, Step: 2.ServiceB

  12. Name: ServiceUserName, Value: UATusernameC, Environment: UAT, Step: 3.ServiceC

  13. Name: ServiceUserName, Value: PRODusernameA, Environment: PROD, Step: 1.ServiceA

  14. Name: ServiceUserName, Value: PRODusernameB, Environment: PROD, Step: 2.ServiceB

  15. Name: ServiceUserName, Value: PRODusernameC, Environment: PROD, Step: 3.ServiceC

  16. Name: ServicePassword, Value: DEVpasswordA, Environment: DEV, Step: 1.ServiceA

  17. Name: ServicePassword, Value: DEVpasswordB, Environment: DEV, Step: 2.ServiceB

  18. Name: ServicePassword, Value: DEVpasswordC, Environment: DEV, Step: 3.ServiceC

  19. Name: ServicePassword, Value: SITpasswordA, Environment: SIT, Step: 1.ServiceA

  20. Name: ServicePassword, Value: SITpasswordB, Environment: SIT, Step: 2.ServiceB

  21. Name: ServicePassword, Value: SITpasswordC, Environment: SIT, Step: 3.ServiceC

  22. Name: ServicePassword, Value: UATpasswordA, Environment: UAT, Step: 1.ServiceA

  23. Name: ServicePassword, Value: UATpasswordB, Environment: UAT, Step: 2.ServiceB

  24. Name: ServicePassword, Value: UATpasswordC, Environment: UAT, Step: 3.ServiceC

  25. Name: ServicePassword, Value: PRODpasswordA, Environment: PROD, Step: 1.ServiceA

  26. Name: ServicePassword, Value: PRODpasswordB, Environment: PROD, Step: 2.ServiceB

  27. Name: ServicePassword, Value: PRODpasswordC, Environment: PROD, Step: 3.ServiceC

  28. Name: AppRoot, Value: D:\OurProject\Services, Environment: non-scoped, Step: non-scoped

  29. Name: ServiceInstallPath, Value: #{AppRoot}#{ServiceName}, Environment: non-scoped, Step: non-scoped

  30. Name: LogRoot, Value: D:\OurProject\Logs, Environment: non-scoped, Step: non-scoped

  31. Name: ServiceLogPath, Value: #{LogRoot}#{ServiceName}, Environment: non-scoped, Step: non-scoped

  32. Name: ShareRoot, Value: \NetworkShareDEV, Environment: DEV, Step: non-scoped

  33. Name: ShareRoot, Value: \NetworkShareSIT, Environment: SIT, Step: non-scoped

  34. Name: ShareRoot, Value: \NetworkShareUAT, Environment: UAT, Step: non-scoped

  35. Name: ShareRoot, Value: \NetworkSharePROD, Environment: PROD, Step: non-scoped

  36. Name: InputLocation, Value: #{ShareRoot}#{ServiceName}\InputFolder, Environment: non-scoped, Step: non-scoped

  37. Name: OutputLocation, Value: #{ShareRoot}#{ServiceName}\OutputFolder, Environment: non-scoped, Step: non-scoped

  • Developers can View/Create/Update these variables, and deploy to the DEV servers:
    1), 2), 3), 4), 5), 6), 16), 17), 18), 28), 29), 30), 31), 32), 36), 37)

  • Testers can View all variables, but they can only Create/Update these variables, and deploy to the SIT servers:
    1), 2), 3), 7), 8), 9), 19), 20), 21), 28), 29), 30), 31), 33), 36), 37)

  • Supports can View all variables, but they can only Create/Update these variables, and deploy to the UAT/PROD servers:
    1), 2), 3), 10), 11), 12), 13), 14), 15), 22), 23), 24), 25), 26), 27), 28), 29), 30), 31), 34), 35), 36), 37)

So as you can see, we do not want everyone to have full access to everything, but somehow they need to be able to view, create or update the “non-scoped” variables. In Octopus v1.6, we can achieve the business goal above, however in Octopus v2, we can no longer do so.

Please investigate and advise how we can achieve the goal above in Octopus v2?

Thanks for the help.
Canny

Hi Canny,

Thanks for the examples. The problem that Nick described is that if one of those variables was referenced by another variable, it does essentially allow a ‘Developer’ to override a ‘Production’ scoped variable. For example, lets take these variables:

Name: ShareRoot, Value: \NetworkShareDEV, Environment: DEV, Step: non-scoped
Name: ShareRoot, Value: \NetworkShareSIT, Environment: SIT, Step: non-scoped
Name: ShareRoot, Value: \NetworkShareUAT, Environment: UAT, Step: non-scoped
Name: ShareRoot, Value: \NetworkSharePROD, Environment: PROD, Step: non-scoped

Now, suppose that you use the ‘Custom installation directory’ feature in Octopus to have the files copied to your file share. You want to vary it by environment, so you bind the value:

 #{ShareRoot}

Internally, we have a variable that looks like this:

 Octopus.Action.Package.CustomInstallationDirectory = #{ShareRoot}

This is a system-defined variable that we set based on what you bind in the UI.

Now, the developer can’t edit the value of ShareRoot, but they CAN create a new, unscoped variable:

Octopus.Action.Package.CustomInstallationDirectory = \NetworkSharePROD (unscoped)

This isn’t just a problem with the way we manage variables internally, but any time you bind a variable. For example, if you had this:

  ConnectionString = Server=#{SqlServer};Database=OurDB;trusted_connection=true
  SqlServer = SQLPROD01 (scope: Production)
  SqlServer = SQLUAT01 (scope: UAT)

A bad developer could just edit the un-scoped variable:

  ConnectionString = Server=SQLProd01; (unscoped)

Hopefully you can see why this is a problem, and why we decided not to allow editing of unscoped variables.

However, I do see the practical aspects of what you described. Besides, changes to variables are audited, so if someone does try to work around the system you’ll at least be able to work out who. So we’re going to do this in 2.4 - not by default, but by giving you the ability to edit/define your own roles, and to add a special “edit non-environment scoped variables” permission to your custom role.

Hope that helps to explain why we we’re reluctant to do this initially.

Paul

Hi Paul,

Thanks a lot for the understanding. Yes we are aware of the security concern that you’ve raised. Unfortunately our business requires people in different groups to manage their environments, and that involves setting up and editing non-scoped variables, so adding this flexibility in Octopus 2 will definitely help. And like what you’ve stated, we often audit the variables to make sure the security is not tampered.

We look forward to seeing these new optional features in Octopus 2.4 which allow customising roles and editing non-scoped variables. Do you have a rough idea of when Octopus 2.4 will be available?

Many thanks for your help.
Canny

Hi Canny,

We expect to release a pre-release version for testing next week!

Regards,

Paul Stovell
Octopus Deploy
W: octopusdeploy.com | T: @octopusdeploy http://twitter.com/octopusdeploy

Hi Paul,

Awesome! Thanks a lot for the update. We’ll try it out next week.

Have a nice long weekend.

Best regards,
Canny

Hi Paul,

Thanks for great work. We’ve downloaded Octopus 2.4.2 and set up a new role to “View” and “Edit” non-environment scoped variables.

However there is a bug in this feature. After adding members to this new role, all members are able to View and Edit all variables which include the non-environment scoped ones and the environment scoped ones.

Here is the story :-

We have the following requirements:

  • Developers - can view / edit variables of the DEV environment, and non-environment scoped variables.
  • Testers - can view / edit variables of the SIT environment, and non-environment scoped variables.
  • Support - can view / edit variables of the UAT and PROD environments, and non-environment scoped variables.

We have set up a new role “Global Variable Editor” which has the following permission enabled:

  • Edit non-environment scoped variables belonging to a project or library variable
    set
  • View non-environment scoped variables belonging to a project or library variable set

We have added a new Team “Non-Environment Scoped Editor” with the new “Global Variable Editor” role, and Developers, Testers and Support as the Members.

We have also configured:

  • Developers Team, which is the Project Contributor for the DEV environment.
  • Testers Team, which is the Project Contributor for the SIT environment.
  • Support Team, which is the Project Contributor for the UAT and PROD environments.

After saving the changes, we’ve logged in as Developers, Testers and Support, and find out that each member is able to view and edit all variables which include non-environment scoped variables, and also variables specified for DEV, SIT, UAT, and PROD.

Can you please take a look?

Thanks for the help.

Hi Canny,

When you set up a team with your “Global Variable Editor” role, the team needs to be scoped to environments in order for this to work.

Attached are three screenshots. I configured my “Project contributors” role to allow editing of unscoped variables. I have a user called “fred” who I put in that role. When my administrator user looks at the variables, he can see all three values, but when “fred” looks at the variables, he can only see the values scoped to his environment, or with no scope. He can’t see the value scoped to acceptance.

Hope that helps!

Paul

Screen_Shot_2014-05-08_at_9.29.54_am.png

Hi Paul,

Thanks for the explanation. We’ve tried your suggestion which is scoping the environment for the “Non-Environment Scoped Editor” team, but the result is the same.

Here is more info:

We have scoped the “Non-Environment Scoped Editor” team for the “DEV” environment, the Role is “Global Variable Editor”, and the Member is “Developer”. And then we’ve logged in as Developer after saving the changes, but the same problem still exists.

I have attached 3 screenshots to show you how this has been set up. Can you please take a look and advise what has gone wrong?

Thanks a lot for your help.

Best regards,
Canny

Hi Canny,

What you have set up looks right. Can you send me a screenshot of any other teams that the “developer” user is in? I suspect they might have project contributor permissions for a different environment which is giving them more access than they should.

Paul

Hi Paul,

I have collected screenshot of every Team with “developer” in it. Please take a look.

Thanks for your help.

Best regards,
Canny

Hi Paul,

I think I’ve discovered where the bug is. The problem is caused by the Environment Viewer team which uses the ‘Environment Viewer’ role (please refer to the screenshot). We want ‘developer’ to be able to view all environments and machines, so we’ve added this team.

However apart from allowing ‘developer’ to view the environments and machines, the ‘Environment Viewer’ role also enables ‘developer’ to view and edit variables for all environments. And this looks like a bug to me.

If I remove the Environment Viewer team with the corresponding role, and log in Octopus as ‘developer’, then the variables page looks correct.

Can you please look into this bug?

Thanks for your help.
Best regards,
Canny