From 76f88790c036ee31ee92fcf12434668e43534531 Mon Sep 17 00:00:00 2001 From: CPol Date: Tue, 8 Aug 2023 06:29:37 +0000 Subject: [PATCH] GITBOOK-440: change request with no subject merged in GitBook --- .../kubernetes-security/kubernetes-pivoting-to-clouds.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md b/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md index 7c074a1470..0b36ac2aec 100644 --- a/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md +++ b/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md @@ -158,6 +158,14 @@ curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/inst gcloud auth list ``` +Check the following command to authenticate in case needed: + +{% code overflow="wrap" %} +```bash +gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json +``` +{% endcode %} + {% hint style="warning" %} As an attacker inside K8s you should **search for SAs** with the **`iam.gke.io/gcp-service-account` annotation** as that indicates that the SA can access something in GCP. Another option would be to try to abuse each KSA in the cluster and check if it has access.\ From GCP is always interesting to enumerate the bindings and know **which access are you giving to SAs inside Kubernetes**.