For a curl request to a metadata api, it requires the -H Metadata-Flavor:Google header. But I am already authenticated within the instance so how does a static header with pre-defined value of Google help with security and trusting the source of the request? What is being passed in the request internally for the server to trust the request?
2 Answers
Interesting question, and one I don’t have a strong answer for. But let’s this as a discussion piece:
First, we’ll take the explanation of why this header exists from the Storing and retrieving metadata article on GCP
This header indicates that the request was sent with the intention of retrieving metadata values, rather than unintentionally from an insecure source, and lets the metadata server return the data you requested. If you don’t provide this header, the metadata server denies your request.
Echoing points already made, this doesn’t really do much to secure the metadata. It just makes it slightly more obscure. There’s no specific authentication occurring, nor protection beyond the header that I can see. There may be some deeper workings in place here, but it seems with an SSRF attack and the required header, the same data could easily be taken.
Interesting, AWS has recently announced security upgrades to their instance metadata service, after it became the vector for a significant breach a few months ago. GCP seems to already be able to effectively disable the instance metadata by removing its permissions from the GCE Service Account, but I haven’t tested this to be sure.
Welcome any other thoughts on this topic also!
From a VM i created inside GCP, test-03, it does not see the ssh-key that was used to connect via the cloud console. Any idea why this would happen?
[tw@test-03 ~]$ curl -H "Metadata-Flavor:Google" metadata.google.internal/computeMetadata/v1/project/attributes/ssh-keys/
The requested URL /computeMetadata/v1/project/attributes/ssh-keys/ was not found on this server. That’s all we know.
In many cases in attacks against Cloud services one of the "hacker"s targets is the metadata endpoint. Access to this endpoint could allow them to steal the SSH key used by the instance for example.
Adding this header protects against some attack types such as SSRF.
Great Question. Also wondering why cant the insecure source also put the Metadata-Flavor:Google in their request ? Does not make sense
Another interesting thing, if you invoke the metadata API directly from cloud shell, you don’t have to specify this header. So the header is not much about the "security".