Variable Permissions when Role is Scoped to an Environment

[OctopusSchaff]

I am building a custom role for my automated builder to create and deploy a release. As part of that process, I need to read out a Variable so I know which of my tenants to deploy to (Blue or Green).

The role has the permission VariableView granted to it. And the team has the role granted to it, with the a restriction to the Dev environment.

My current plan is to have a project variable called CurrentBlueGreenState. It will be set for each environment my project runs in. I am using a REST api invocation to get this value.

When the variable is setup like this, the REST call works correctly:

Name                                   Value                      Scope
CurrentBlueGreenState                  Blue                       Dev
CurrentBlueGreenState                  Green                      Staging,  Prod

I get the value Blue and the variable environments with Green are not returned.

But once I change it to this:

Name                                   Value                      Scope
CurrentBlueGreenState                  Blue                       Dev,  Staging 
CurrentBlueGreenState                  Green                      Prod

Then nothing is returned.

Is this by design? I would expect that, since I have view permissions for Dev, that I would get back the value Blue for the variable. I am confused why, just because the value is also used for Staging, it blocks my user from seeing the value for Dev.

What are the rules for when a scoped variable can and cannot be seen?

[Kenneth_Bates]

Hi @OctopusSchaff,

Thanks for getting in touch! This is a great question, and my first thought is that this is not the intended behavior. I’m thinking a variable value with multiple environment scopes should still be displayed to a user whose permissions are scoped to just one of those environments. I ran through a test and I’m seeing this same behavior, so I’m going to raise this internally to see if I’m missing any important detail, or if it’s a bug which I’ll then raise a bug report for. I’ll keep you posted.

If you have any questions or concerns going forward, please let me know!

Best regards,

Kenny

[Kenneth_Bates]

Hi @OctopusSchaff,

Just wanted to give an update after a bit more testing and discussion. So this turns out to actually be the intended and correct behavior. The reasoning boils down to the fact that a user who has permissions for one environment should not have access to values scoped outside of that environment. Say if they had VariableEdit scoped to Dev, then updating that variable value would affect how the variable would resolve on deployments to Staging, which is outside of their scope and should be locked down.

If you’re needing one value scoped to two environments where one is outside the scope of the user’s permissions, I’m thinking the best way to handle that is to split the value into two, keeping the same value for both but differentiate the two by scoping one to Dev and one to Staging.

I hope that helps. Let me know what you think!

Best regards,

Kenny

[OctopusSchaff]

Thank you for the reply. That is not how I would have built it, but I can work with that.

Thanks again