-
Notifications
You must be signed in to change notification settings - Fork 862
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
Correct IMDS resource ID query parameter #22650
Conversation
Does this need a changelog entry? |
@@ -34,14 +34,14 @@ const ( | |||
identityServerThumbprint = "IDENTITY_SERVER_THUMBPRINT" | |||
headerMetadata = "Metadata" | |||
imdsEndpoint = "http://169.254.169.254/metadata/identity/oauth2/token" | |||
miResID = "mi_res_id" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come this is still needed (in what scenarios)?
I can't easily tell from the logic below where we'd use this one vs the MSI one.
Both seem to be wrapped around if id.idKind() == miResourceID
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still need this for App Service. Each platform we support has a different API, so the query parameter we need to set depends on the platform. id
in the line you pasted is the value of the parameter i.e. the resource ID.
@@ -437,7 +437,7 @@ func (c *managedIdentityClient) createCloudShellAuthRequest(ctx context.Context, | |||
log.Write(EventAuthentication, "WARNING: Cloud Shell doesn't support user-assigned managed identities") | |||
q := request.Raw().URL.Query() | |||
if id.idKind() == miResourceID { | |||
q.Add(qpResID, id.String()) | |||
q.Add(miResID, id.String()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most places seem to keep using the mi string, instead of msi, but the PR description is implying we should convege and only use msi.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need both. We should use "msi_res_id" for IMDS (and implicitly, anything resembling IMDS). For other platforms such as App Service, "mi_res_id" is correct. Edit: whoops, not according to the docs. I'll investigate App Service next 🕵️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this was interesting. The App Service doc was changed after we implemented this feature because a reader saw that other APIs use msi_res_id
and concluded mi_res_id
was a typo. It isn't: mi_res_id
is correct and App Service ignores msi_res_id
. I opened MicrosoftDocs/azure-docs#121176 to fix the doc.
IMDS observes both
msi_res_id
andmi_res_id
as the query parameter specifying an identity by its resource ID. We should prefermsi_res_id
because it's the documented parameter and because Azure Container Instances, which has a different implementation based on the IMDS API, observes onlymsi_res_id
.