You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
ASO requires a Service Principal (actually it no longer does, but it still supports deployment using a Service Principal). The Service Principal belongs to an Entra ID tenant. This tenant may have Conditional Access policies configured which prevent "token issuance". That is, they prohibit authentication flows in which a client ID and secret are exchanged for an access token (at least from certain machines - it still seems to work from within AKS clusters, which is why ASO itself is not broken by this).
In these cases (the MSIT tenant is an example), the ASO deployment command fails at the stage of checking the service principal. That is because we attempt to check subscription access using the Service Principal's own credentials (which are a client ID and secret), rather than those of the signed-in user.
This means we probably have to remove the functionality to check which subscriptions the service principal can access. We can use the signed-in user's token to examine role assignments, but it is very possible the user will not have the required permissions to do this, even if the service principal does. We don't want this command to fail in those cases, and so it will be simpler and more robust to remove the check altogether.
Mention the platform you are using
Occurs on all platforms
To Reproduce
Run the ASO command in any cluster on the MSIT tenant, and enter a service principal's client ID and secret.
Expected behavior
The extension checks which subscriptions the service principal can access without error.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]
Smartphone (please complete the following information):
Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
Describe the bug
ASO requires a Service Principal (actually it no longer does, but it still supports deployment using a Service Principal). The Service Principal belongs to an Entra ID tenant. This tenant may have Conditional Access policies configured which prevent "token issuance". That is, they prohibit authentication flows in which a client ID and secret are exchanged for an access token (at least from certain machines - it still seems to work from within AKS clusters, which is why ASO itself is not broken by this).
In these cases (the MSIT tenant is an example), the ASO deployment command fails at the stage of checking the service principal. That is because we attempt to check subscription access using the Service Principal's own credentials (which are a client ID and secret), rather than those of the signed-in user.
This means we probably have to remove the functionality to check which subscriptions the service principal can access. We can use the signed-in user's token to examine role assignments, but it is very possible the user will not have the required permissions to do this, even if the service principal does. We don't want this command to fail in those cases, and so it will be simpler and more robust to remove the check altogether.
Mention the platform you are using
Occurs on all platforms
To Reproduce
Run the ASO command in any cluster on the MSIT tenant, and enter a service principal's client ID and secret.
Expected behavior
The extension checks which subscriptions the service principal can access without error.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: