-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
GCE metadata proxy blocks instance identity & recursive calls, & excludes port from redirects #51302
Conversation
} | ||
|
||
# Allow for REST discovery. | ||
location = / { | ||
if ($args ~ "recursive=true") { |
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.
have you tried if recursive=1
or recursive=True
or recursive=y
etc also effective on GCE metadata server. If it's more permissive than we blacklisted here, it's still a problem.
return 403 "?recursive calls are not allowed by the metadata proxy."; | ||
} | ||
proxy_pass http://169.254.169.254; | ||
} | ||
location = /computeMetadata/ { | ||
if ($args ~ "recursive=true") { | ||
if ($args ~* "recursive") { |
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.
I'm now afraid this will prevent ?recursive=false
, too. @ihmccreery if you've figured out the values that count as true
, I think we should add them here. (But then I'll probably worry about if this $args~* check actually normalizes the URLencoding.)
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.
I feel okay about blocking ?recursive=false
(and ?recursive=0
, etc.), since, as far as I can tell, there's no conventions on a strict set for what to accept as booleans. Params are just a bunch of strings that can be interpreted however the server wants.
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.
(From some messing around, true
, 1
, yes
, and y
are all accepted.)
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.
(on
is also accepted, tried because I found spring-framework's StringToBooleanConverter.java.)
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.
On a second thought maybe blocking ?recursive
is fine. (We can always relax it later if we get a user request. What I'm actually worried is Google rolling out a software/daemon that runs inside the VM and that makes a ?recursive=
query to the metadata server, that sounds apocalyptic.)
I'm not familiar with the nginx.conf language enough to see if it warrants a pattern like ^recursive=
(maybe at least leave the =
in for more precise matching).
@ahmetb I made the regex's a bit more explicit, at your suggestion. If this looks good to you, can I get an lgtm? Ping @mikedanese @Q-Lee for review? |
/lgtm |
/assign @mikedanese |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahmetb, ihmccreery, mikedanese Associated issue: 8867 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
} | ||
|
||
# Allow for REST discovery. | ||
location = / { | ||
if ($args ~* "^(.+&)?recursive=") { | ||
return 403 "?recursive calls are not allowed by the metadata proxy."; |
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.
you should mention the SECURE setting in all of these errors so people realise they are getting this error from the proxy rather than the metadata server itself, and know what to change if they need it to work.
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.
This isn't GKE-specific, so we can't mention the GKE feature. The error message needs to also apply to GCE (hence 'metadata proxy').
Automatic merge from submit-queue (batch tested with PRs 51628, 51637, 51490, 51279, 51302) |
Commit found in the "release-1.7" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked. |
Automatic merge from submit-queue Add a container & job spec to check metadata concealment correctness This checks for some of the fixes made in kubernetes/kubernetes#51302. Ref #8867. I'm unsure of where this should live, but this seems like as good a place as any? @spxtr We discussed, and I'd rather just check it in here now.
What this PR does / why we need it: Metadata proxy blocks instance identity & recursive calls, and no longer includes port in redirects (it was serving redirects to
http://metadata.google.internal:988
, which doesn't resolve. Ref #8867.Special notes for your reviewer: Container is defined https://github.com/kubernetes/contrib/tree/master/metadata-proxy; I plan to send a separate PR to remove the
nginx.conf
directly in the container to reduce confusion.Release note: