Installer: Azure AD Admin Consent Is Required For Azure Installation

Created on 13 Sep 2019 · 16Comments · Source: openshift/installer

Version

4.2.0

Platform:

Azure

What happened?

Azure AD admin consent is required for the installation, which is a blocker for many enterprise users. This is not required before.

What you expected to happen?

Make this become optional, or something can be configured after installation.

How to reproduce it (as minimally and precisely as possible)?

Install OpenShift 4.2 on Azure

Anything else we need to know?

Enter text here.

References

enter text here.

lifecyclstale

Source

nichochen

Most helpful comment

@abhinavdahiya - I'm running into this same issue in cluster deployments because my tenant admin doesn't grant me the "service principal creation and permission granting" permission that @qike-ms mentioned above. Is there anything being done to mitigate this?

asinn826 on 2 Oct 2019

👍2

All 16 comments

Azure AD admin consent is required for the installation, which is a blocker for many enterprise users. This is not required before

The installer doesn't need it. We need the service principal to have certain permission that only tenant admin can provide... So I'm not sure what's the blocker here.

abhinavdahiya on 13 Sep 2019

https://github.com/openshift/installer/blob/master/docs/user/azure/credentials.md

az ad app permission add --id <AppId> --api 00000002-0000-0000-c000-000000000000 --api-permissions 824c81eb-e3f8-4ee6-8f6d-de7f50d565b7=Role

Above step required Admin Consent, but for enterprise users, sometimes it's complicated and time consuming to request AD admin to grant the required consent. I tried to install without having the required consent, the installation failed.

What features are depending on this permission? Something related to the core of OCP4, or something which is good to have?

nichochen on 13 Sep 2019

What features are depending on this permission? Something related to the core of OCP4, or something which is good to have?

It is required by core OCP4 components like the machine-api (which is used to create compute machines), ingress-operator (which provides the OpenShift Routes), registry-operator (which uses it to create the storage account backing the internal registry).

abhinavdahiya on 13 Sep 2019

I remember back in June, the installer is able to deploy clusters without this permission. The machineset and router operator were working fine as well.

According to the id, the permission is the following one:
Azure Active Directory Graph -> Application.ReadWrite.OwnedBy

nichochen on 13 Sep 2019

I remember back in June, the installer is able to deploy clusters without this permission. The machineset and router operator were working fine as well.

That was because those components got the service principal provided to the installer, which all pretty high permissions on the ENTIRE subscriptions ie all the resource groups. To create smaller service principals for our components that are scoped to only the resource group of the cluster, we had to require these new permissions.

abhinavdahiya on 13 Sep 2019

That's a good idea. However, would it be better to let user decide whether they would like to have this fine-grained control?

nichochen on 13 Sep 2019

@abhinavdahiya I haven't investigated this further, but maybe this might help you get a better user experience?
https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow

serbrech on 16 Sep 2019

Friendly ping. We think using OBO (on-behalf-of) is a more secure way than giving the "service principal creation and permission granting" permission to another service principal. @abhinavdahiya what do you think?

qike-ms on 20 Sep 2019

asinn826 on 2 Oct 2019

👍2

I was looking at an implementation in #2855 that would not require admin consent.

The idea was to allow Azure account administrators create a resource group, and give appropriate permissions to the service principal for the resource group only.

The implementation allowed the installer to accept existing resource group and associated service principal to operate on that resource group. From a terraform perspective this removed the necessity for elevated privileges for the openshift installer.

One of the next items to prove out was the Credentials Minter cloud-credential-operator but as I understand the credentials minter design, this should work as a stated valid configuration is to

Install with a set of credentials that has all permissions needed for all OpenShift components. If this path is taken, those credentials will be shared by all components, as the credential operator cannot mint new credentials

So in other words the net effect would be that

some components in the cluster would have higher privileges than functionally required (owner on resource group)
no components in the cluster would have privileges outside the resource group

So, from a security perspective I think the net effect is that the attack surface is somewhat increased, but the blast radius is greatly decreased.

hassenius on 18 Feb 2020

👍1

@abhinavdahiya Hi, I'm curious what exactly requires the Admin Consent from a cluster operator perspective? You state in this PR: https://github.com/openshift/installer/pull/2855 that it is the cloud-credential CO (cred-minter). Anything else?

What is the impact of not having Admin Consent set for a cluster? I gave a newly created service principal "User Access Administrator" permission and was able to install a 4.3 cluster via IPI just fine, do a micro update from 4.3.0 to 4.3.1, scale one of the MachineSets to create a new Worker node, etc. All worked without issue.

Basically step 6b and 6c listed here I did not do: https://docs.openshift.com/container-platform/4.3/installing/installing_azure/installing-azure-account.html

Can you help clear up the confusion?

novacain1 on 25 Feb 2020

I was curious about what @novacain1 mentioned above so I tried an install of 4.3 using the same instructions he linked (https://docs.openshift.com/container-platform/4.3/installing/installing_azure/installing-azure-account.html). I also skipped steps 6b and 6c and got my cluster working in the end.

@abhinavdahiya - is there any reason why steps 6b and 6c are needed in the doc above for 4.3? Should I be expecting something missing in my cluster soon? Or should the docs be updated?

asinn826 on 10 Mar 2020

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot on 8 Jun 2020

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

openshift-bot on 8 Jul 2020

/remove-lifecycle rotten