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**.