Note: I disclosed this private and was asked to open in public

What happened:

A pod probe can be configured to send readiness probes to arbitrary destinations, including localhost on the node. This is similar to CVE-2020-8555.

Kubernetes Version:
v0.20.0 (Kind) and v1.19.6 (GKE) were tested. I suspect its an issue on all versions

Steps To Reproduce:

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: docker.io/kennethreitz/httpbin
    name: httpbin
    readinessProbe:
      httpGet:
        host: 169.254.169.254
        httpHeaders:
        - name: Metadata-Flavor
          value: Google
        path: /computeMetadata/v1/
        port: 80
        scheme: HTTP

This shows an example of accessing GCE metadata.

Other possible targets are localhost endpoints, such as 127.0.0.1:2381/metrics (etcd metrics), or external targets (httpbin.org, for example).

Note that because this is coming from the node, we can also access internal targets (pods) running on the same node, bypassing NetworkPolicy restrictions.

In generally, the attack only allows sending GET requests, and does not allow viewing the data in the response.

The status code of a response is, however, returned in pod events: "HTTP probe failed with statuscode: .... This could be used to extract some degree of private information about the node.

Additionally, access to kubelet logs with verbosity >= 4 will log the full body, which would make this much work severe.

Other possible risks are that these external calls are now coming from the k8s node which may have differing firewall/routing rules than a pod would.

What you expected to happen:

I don't know. Its certainly a tricky problem since its a part of the API and hard to change.