Running into an issue, and unsure if i am doing something wrong or missing something obvious.
Setting up a new environment in Azure and we have 2 azure regions in play. AusEast and AusSouthEast.
The web apps deployed to these regions are in the same subscription, and the account i am using to add the deployment targets has contributor permissions for the resource groups in both subscriptions.
Yet when i try to add an app service from this account, i only ever see the resources in AusSouthEast and not the AusEast resources.
Is there something i am missing where i cannot use the same account across multiple regions in azure? Or is this some other arbitrary limitation.
Firstly, you might want to constrain the service principal to a single resource group, in which case, you just need to assign it the Contributor role on the resource group.
Next, if you want to get even more granular you can constrain the service principal to a single resource, e.g. a Web App. In this case, you have to assign the Contributor role on the Web App and explicitly assign the Reader role on the subscription itself.
It sounds like it might be only using one Resource Group instead of checking the Subscription for any other Resource Groups to use, if you use the Azure Account in a Run an Azure Script step to list the resource groups & web apps, are you able to see all the resources?
az group list --query "[?location=='australiaeast']"
az group list --query "[?location=='australiasoutheast']"
Iāll dig into this and see if I can spot anything odd going on, feel free to reach out with any questions!
I have since altered the roles and added Reader to the subscription, this resulted in a minor change, it now shows me an additional service in a different resource group in AustraliaSouthEast. So i know the reader change took effect, however it is still only showing targets in AustraliaSouthEast and none from AustraliaEast.
I tried adding you az query to a Run an Azure Script Step, but it fails saying
ObjectNotFound: The term 'az' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
It looks like it is still fixating on resources in one site and not aware of the other, even though it has reader across the sub
I havenāt been able to reproduce this and have confirmed that it doesnāt actually require Reader on the Subscription Group and should work fine with just the Contributor role on each Resource Group only. It seems like thereās something preventing access on your end, could there be any Deny Assignments configured, or condition?
The Azure script looks like it failed to find the Az CLI tooling on the target, if the option āUse Azure tools pre-installed on the workerā is selected then the Azure CLI az command will need to be available in the $PATH, check out our docs about it here:
If youād like to send through any screenshots of your configuration to our Secure Upload Portal, Iād be happy to see if I can spot whatās going on. Iād also like to confirm which version of Octopus you are using?
Example of the role assignments I configured on each Resource Group:
Agreed, this is definitely one of the more perplexing issues Iāve seen!
If you use the āCheck Accessā tool under Access Control (IAM), are you able to confirm that the Service Principal has access to all of the resources inside the Resource Group?
Otherwise using the Azure CLI with that service principal using the --debug flag might reveal more info about whatās going on. Is it possible there is Conditional Access configured? E.g. MFA required
It might be worth getting Azure support involved if you arenāt able to locate the issue, unfortunately Iām not sure how much help I can provide since it seems Octopus is working fine with the other targets.
In testing even my account cannot see the app services in Aus East via the cli tool, even though they are there in the portal. But the issue is only present in one of our subscriptions. Very strange times indeed
So further follow up, this appears to be an issue within the az apiās, but it also highlights that the octopus cli relies upon that also.
After playing around for a while we realised the āaz webapp listā command was only returning the endpoints from one region for this subscription, however if we ran āaz webapp list -l australiaeastā and explicitly set the location it shows the web apps from that region. It also worked when i specified the resource group for the deployment target.
Now based upon that we tried using the octopus cli, interactively that must use the equivalent of az webapp list to find the list of webapps. But here is where i think the octopus cli is letting users down is when i use the cli arguments it doesnāt appear to pass through the resource group (even though i am specifying the name of the RG).
Is there some other way i can add the target given i have all the values available whilst we wait for an MS reply, deployments to the targets are working for us from the cli, so expect if we can get it registered in Octopus, we will be able to deploy.
Iāll dig into this and check into how we are handling location with our Azure targets and check for any improvements we can make. Iāll keep you posted with any findings or updates!
