Unable to add credential for Azure cloud

Bug #1869939 reported by Camille Rodriguez on 2020-03-31
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
High
Ian Booth

Bug Description

I followed the instructions from here https://discourse.juju.is/t/using-microsoft-azure-with-juju/1086 and I run into an error when trying to add azure credentials.

I did successfully the azure login, in the browser, and it prints out my azure info in the cli command. However, when I try to add the credential to juju, I run into this :

```
ERROR finalizing credential: cannot get service principal: creating service principal: graphrbac.ServicePrincipalsClient#Create: Failure responding to request: StatusCode=403 -- Original Error: Authorization_RequestDenied: When using this permission, the backing application of the service principal being created must in the local tenant
```

The Azure account is an Entreprise account, could it be why this is failing on permissions?

Thank you,
Camille Rodriguez

More info:
I tried with the latest stable 2.7 juju version, as well as juju 2.8-beta1-eoan-amd64

Ian Booth (wallyworld) wrote :

The issue might be similar to the issue reported here

https://social.msdn.microsoft.com/Forums/azure/en-US/1fef33cd-48f2-45d2-8428-28d238751621/adding-cdn-to-azure-active-directory-error?forum=azurecdn

It may be that Juju is expecting a level of access to the cluster that the credential does not allow. Maybe the level of required access by Juju can be downgraded.

tags: added: azure-provider
Changed in juju:
status: New → Triaged
importance: Undecided → High
milestone: none → 2.8-beta1
Ian Booth (wallyworld) on 2020-04-02
Changed in juju:
milestone: 2.8-beta1 → 2.8.1

Yes it might be the same error. Since this is with my Enterprise account, I may not have the global admin permission. However, that permission should not be needed to create vms and deploy workload in Azure.

Ian Booth (wallyworld) wrote :

Yes, 100% agree. We need to spend time figuring out how to set up a suitable account to be able to reproduce so we can work on a fix.

Hi, is there an update on this bug?

Pete Vander Giessen (petevg) wrote :

@camille.rodriguez: this bug is queued up for investigation for the 2.8.1 release, but right now we're focused on squashing the remaining 2.8-rc1 bugs in preparation for that impending release. There should be more activity on this one once we get the release candidate out the door.

Tim Penhey (thumper) wrote :

We are trying to work out how to reproduce this with our credentials.

Changed in juju:
milestone: 2.8.1 → 2.8-next
Heather Lanigan (hmlanigan) wrote :
Download full text (3.2 KiB)

@thumper: While working on 1860717, I was able to reproduce with our credentials.

Steps:
* juju deploy ubuntu
* juju scp $GOPATH/bin/juju ubuntu/0:.
* juju ssh ubuntu/0
* apt purged lxd
* curl -L https://aka.ms/InstallAzureCli | bash
* exit
* juju ssh ubuntu/0
* az login
  sent me to a website with a code to authenticate. used our crews in last-pass.
* $ ./juju autoload-credentials --debug
14:37:18 INFO juju.cmd supercommand.go:91 running juju [2.9-beta1 0 db25750a036cca13d9b6d4796366a0c6efb305f1 gc go1.14.4]
14:37:18 DEBUG juju.cmd supercommand.go:92 args: []string{"./juju", "autoload-credentials", "--debug"}
14:37:18 INFO cmd controller.go:454 This operation can be applied to both a copy on this client and to the one on a controller.
14:37:18 INFO cmd controller.go:470 No current controller was detected and there are no registered controllers on this client: either bootstrap one or register one.
14:37:18 INFO cmd detectcredentials.go:163
Looking for cloud and credential information on local client...
14:37:18 INFO juju.util.exec exec.go:209 run result: exit status 1
14:37:18 DEBUG juju.kubernetes.provider detectcloud.go:24 failed to query local microk8s: microk8s is not installed: microk8s not found
14:37:18 DEBUG juju.provider.azure.internal.azurecli az.go:68 running az account list -o json
14:37:19 DEBUG juju.provider.azure.internal.azurecli az.go:68 running az cloud list -o json
14:37:20 DEBUG juju.provider.azure.internal.azurecli az.go:68 running az account get-access-token --subscription 2eebf55a-1e02-45d8-a299-02aed8aea00b --resource https://graph.windows.net/ -o json
14:37:21 DEBUG juju.provider.azure.internal.azurecli az.go:68 running az account get-access-token --subscription 2eebf55a-1e02-45d8-a299-02aed8aea00b --resource https://management.azure.com/ -o json
14:37:22 DEBUG juju.provider.azure credentials.go:126 cannot get credential for Juju QA: cannot get service principal: creating service principal: graphrbac.ServicePrincipalsClient#Create: Failure responding to request: StatusCode=403 -- Original Error: Authorization_RequestDenied: When using this permission, the backing application of the service principal being created must in the local tenant
14:37:22 DEBUG juju.caas.kubernetes.clientconfig k8s.go:280 The kubeconfig file path: "/home/ubuntu/.kube/config"
14:37:22 DEBUG juju.container.lxd connection.go:167 using LXD snap socket: "/var/snap/lxd/common/lxd"
14:37:22 ERROR juju.provider.lxd credentials.go:159 unable to detect local LXC credentials: failed to connect to local LXD: Permission denied, are you in the lxd group?

Please configure LXD by running:
 $ newgrp lxd
 $ lxd init

14:37:22 DEBUG juju.provider.openstack credentials.go:152 neither OS_TENANT_NAME nor OS_PROJECT_NAME environment variable not set
14:37:22 DEBUG juju.provider.openstack credentials.go:155 neither OS_TENANT_ID nor OS_PROJECT_ID environment variable not set
14:37:22 DEBUG juju.provider.openstack credentials.go:152 neither OS_TENANT_NAME nor OS_PROJECT_NAME environment variable not set
14:37:22 DEBUG juju.provider.openstack credentials.go:155 neither OS_TENANT_ID nor OS_PROJECT_ID environment variable not set
No cloud credentials found.
14:3...

Read more...

Ian Booth (wallyworld) wrote :

@Camille can you share the permissions your account has? And perhaps describe how the accounts and tenants have been set up? We need a recipe we can use to replicate your account set up so we can reproduce the issue.

Ian Booth (wallyworld) on 2020-07-07
information type: Public → Private

Hi Ian. The account has been created by IS via this re. I also opened a bug 3 months ago with them regarding this issue : https://portal.admin.canonical.com/C125015/

Ian Booth (wallyworld) on 2020-07-07
Changed in juju:
assignee: nobody → Ian Booth (wallyworld)
Download full text (7.6 KiB)

Sorry about that, it looks like I pressed enter by mistake.

Hi Ian. The account has been created by IS via this request: https://portal.admin.canonical.com/C124783/ . I also opened a bug 3 months ago with them regarding this issue : https://portal.admin.canonical.com/C125015/.

Regarding what happens when I try to add the credential, here is more details :

$ az login
You have logged in. Now let us find all the subscriptions to which you have access...
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "40a524d9-f848-46d4-a96f-be6df491fe15",
    "id": "af632a76-a2ab-42c2-801f-cb4a7471c83a",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Microsoft Azure Enterprise",
    "state": "Enabled",
    "tenantId": "40a524d9-f848-46d4-a96f-be6df491fe15",
    "user": {
      "name": "<email address hidden>",
      "type": "user"
    }
  }
]

$ juju add-credential azure
This operation can be appli...

Read more...

Ian Booth (wallyworld) on 2020-07-07
Changed in juju:
milestone: 2.8-next → 2.8.2
status: Triaged → In Progress
Ian Booth (wallyworld) wrote :

So the canonical.com AD has a Juju CLI enterprise application

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ManagedAppMenuBlade/Overview/appId/cbb548f1-5039-4836-af0b-727e8571f6a9/objectId/68fda228-f98e-4639-8f5c-b8af817f08ea

This app is used during the interactive credential set up in Juju. And I think there's a permissions issue with the tenant id being used. But the account used by the Juju team does not have admin access to change this Juju CLI app, and it's not apparent who set it up.

More investigation needed...

Ian Booth (wallyworld) wrote :

I have managed to get things working by creating an registering a new Azure multi-tenant Juju Enterprise Application in the canonical.com Active Directory. The issue is the existing app is single tenant only and the owner not valid so everything is greyed out and cannot be changed. So a new app is needed, and this means Juju needs to be released with a new app id to use with the credential setup.

information type: Private → Public
Ian Booth (wallyworld) wrote :

This PR https://github.com/juju/juju/pull/11821

has a change which tells juju to use the newly set up "Juju" app in the canonical.com AD when creating a service principal and access token. It fixed the issue I could see locally where juju autoload-credential failed. But my credential always has worked to allow bootstrap so I am not 100% sure of the fix.

Ian Booth (wallyworld) on 2020-07-17
Changed in juju:
status: In Progress → Fix Committed
Changed in juju:
status: Fix Committed → Fix Released
Aymen Frikha (aym-frikha) wrote :

I'm still hitting the same issue here :(

Ian Booth (wallyworld) wrote :

Could you raise a new bug with steps to reproduce and any error messages etc that you see. Also include things like the subscription id being used and the type of credential etc.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers