* go.mod: Add github.com/microsoftgraph/msgraph-sdk-go
* azureclient: Add NewGraphServiceClient
Creates a GraphServiceClient with scope and graph endpoint set
appropriately for the cloud environment (public or US government).
* pkg/util/graph: Add GetServicePrincipalIDByAppID
* armhelper: Use MS Graph to obtain service principal ID
* armhelper: Remove unused authorizer parameter
* Use MS Graph endpoint to validate service principal
I don't think it matters for the purpose of validation, but the
AD Graph endpoint is nearing its end-of-life.
* pkg/cluster: Use MS Graph to obtain service principal ID
* pkg/util/cluster: Use MS Graph to create and delete clusters
* Pretty-print OData errors from MS Graph
To aid debugging failed MS Graph requests.
MS Graph's top-level APIError message is hard-coded and only says
"error status code received from the API". Further details have
to be extracted from the "ODataErrorable" interface type.
* azureclient: Remove ActiveDirectoryGraphScope
No longer used.
* Remove pkg/util/azureclient/graphrbac
No longer used.
* pipelines: Run CodeQL analysis for Go on 1ES Hosted Pool
Vendoring the Microsoft Graph SDK for Go causes memory consumption
during CodeQL analysis to double due to its enormous API surface,
putting it well beyond the memory limit of standard GitHub Action
runners.
I inquired with the Azure organization admins about provisioning
larger GitHub runners, but was directed instead to use the 1ES
Hosted Pool which runs our other CI checks. Since ARO controls
the VM type for Hosted Pool agents, we can use a VM type with
adequate memory for CodeQL analysis with the Graph SDK.
Note: Implemented CodeQL commands in a template in case we
ever decide to move Javascript or Python analysis to
1ES Hosted Pool as well.
Amber Brown
dependabot[bot]
Matthew Barnes