Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install ASO command fails on some tenants #552

Closed
peterbom opened this issue Mar 12, 2024 · 1 comment
Closed

Install ASO command fails on some tenants #552

peterbom opened this issue Mar 12, 2024 · 1 comment
Assignees

Comments

@peterbom
Copy link
Contributor

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.

@peterbom
Copy link
Contributor Author

Fixed by #724

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant