We use Octopus Deploy v2018.5.7 for deploying to Azure. For security reasons, we DON’T give AccountView permission to users as we don’t want users to be able to browse for other projects’ Azure accounts and thereby impersonate one another. Instead we set a project variable to the account ID which then can be used for binding in Azure process steps.
As an unwanted consequence however, the users cannot browse for packages in feeds when lacking this permission as you can see here:
I’m sorry you are having this difficulty with permissions. I’m going to try and reproduce the issue here so I can determine the cause. I’ll let you know shortly how that goes, and if I have any questions about your configuration.
Thank you for getting in contact with us, and I’ll be in touch.
Thank you for your patience. There are a couple of different aspects to this issue that I’d like to address.
When the user without AccountVIew opened an Azure step, the UI was successfully loading the package feeds. However, when it attempted to load the accounts without the required permissions, an error was generated which prevented the feeds from being displayed properly. We’ve developed a fix for this which was released in version 2018.6.7.
The second issue is the loading of the accounts themselves. Denying users who use Azure steps the AccountView permission isn’t a configuration we’d recommend. The fix we’ve just released also hides the account section of the Azure steps with a permissions warning if you are missing the AccountView permission. Your users should still be able to use the Azure Web App and Azure Cloud Service steps via the new Azure targets functionality.
However, the Azure Resource Group step doesn’t use Azure targets, so users without the AccountView permission will be unable to create new Azure Resource Group steps. They should be able to edit an existing step once the account has been supplied by a user who does have the AccountView permission. We thought this was the best balance between supporting your use-case, and keeping the behaviour of the UI consistent. I hope this still supports the workflow you are using.
I’d be happy to hear your feedback on this resolution, and please let me know if we can assist in any other way.
The introduction of Azure targets actually caught us by surprise as late as yesterday (we’ve now upgraded to v2018.5.7) and we’re currently prioritising finding a way for us automate that configuration for the teams. I’m sure we’ll sort this out, otherwise I’ll let you know in another support topic to keep things separated.
When it comes to the Azure Resource Group step, I guess we’ll go with our current setup (which has been our approach for all Azure steps until now):
Users do NOT have AccountView permssion (to avoid cross-account deployments by accidents in our setup with multiple teams deploying to multiple Azure subscriptions)
We’re defining a deployment variable called “AzureAccount” pointing to a unique, automatically created, Azure account for the project
In the Azure steps, the Azure Account is bound to #{AzureAccount}
Let me know if you find this configuration really bad for some reason or if you have any suggestion for how to implement it instead.
Sorry for the late response! I was going through my recent tickets and noticed I had not replied here, so please accept my apologies.
The requirement here is fairly uncommon, and currently I don’t see a better alternative. When we ship the Spaces feature, you may find that you can isolate related users, accounts and projects in a space to avoid cross-contamination, thereby removing the need to limit the AccountView permission. I don’t have any new information on when that feature will be available, apart from that we are actively working on it.
