GCP - Container Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
container.clusters.getThis permission allows to gather credentials for the Kubernetes cluster using something like:
Without extra permissions, the credentials are pretty basic as you can just list some resource, but hey are useful to find miss-configurations in the environment.
Note that kubernetes clusters might be configured to be private, that will disallow that access to the Kube-API server from the Internet.
If you don't have this permission you can still access the cluster, but you need to create your own kubectl config file with the clusters info. A new generated one looks like this:
container.roles.escalate | container.clusterRoles.escalateKubernetes by default prevents principals from being able to create or update Roles and ClusterRoles with more permissions that the ones the principal has. However, a GCP principal with that permissions will be able to create/update Roles/ClusterRoles with more permissions that ones he held, effectively bypassing the Kubernetes protection against this behaviour.
container.roles.create and/or container.roles.update OR container.clusterRoles.create and/or container.clusterRoles.update respectively are also necessary to perform those privilege escalation actions.
container.roles.bind | container.clusterRoles.bindKubernetes by default prevents principals from being able to create or update RoleBindings and ClusterRoleBindings to give more permissions that the ones the principal has. However, a GCP principal with that permissions will be able to create/update RolesBindings/ClusterRolesBindings with more permissions that ones he has, effectively bypassing the Kubernetes protection against this behaviour.
container.roleBindings.create and/or container.roleBindings.update OR container.clusterRoleBindings.create and/or container.clusterRoleBindings.update respectively are also necessary to perform those privilege escalation actions.
container.cronJobs.create | container.cronJobs.update | container.daemonSets.create | container.daemonSets.update | container.deployments.create | container.deployments.update | container.jobs.create | container.jobs.update | container.pods.create | container.pods.update | container.replicaSets.create | container.replicaSets.update | container.replicationControllers.create | container.replicationControllers.update | container.scheduledJobs.create | container.scheduledJobs.update | container.statefulSets.create | container.statefulSets.updateAll these permissions are going to allow you to create or update a resource where you can define a pod. Defining a pod you can specify the SA that is going to be attached and the image that is going to be run, therefore you can run an image that is going to exfiltrate the token of the SA to your server allowing you to escalate to any service account. For more information check:
As we are in a GCP environment, you will also be able to get the nodepool GCP SA from the metadata service and escalate privileges in GCP (by default the compute SA is used).
container.secrets.get | container.secrets.listAs explained in this page, with these permissions you can read the tokens of all the SAs of kubernetes, so you can escalate to them.
container.pods.execWith this permission you will be able to exec into pods, which gives you access to all the Kubernetes SAs running in pods to escalate privileges within K8s, but also you will be able to steal the GCP Service Account of the NodePool, escalating privileges in GCP.
container.pods.portForwardAs explained in this page, with these permissions you can access local services running in pods that might allow you to escalate privileges in Kubernetes (and in GCP if somehow you manage to talk to the metadata service).
container.serviceAccounts.createTokenBecause of the name of the permission, it looks like that it will allow you to generate tokens of the K8s Service Accounts, so you will be able to privesc to any SA inside Kubernetes. However, I couldn't find any API endpoint to use it, so let me know if you find it.
container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.updateThese permissions might allow you to escalate privileges in Kubernetes, but more probably, you could abuse them to persist in the cluster. For more information follow this link.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
