# GCP - Container Privesc

{{#include ../../../banners/hacktricks-training.md}}

## container

### `container.clusters.get`

This permission allows to **gather credentials for the Kubernetes cluster** using something like:

```bash
gcloud container clusters get-credentials <cluster_name> --zone <zone>
```

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]
> 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:

```yaml
apiVersion: v1
clusters:
  - cluster:
      certificate-authority-data:  
      server: https://34.123.141.28
    name: gke_security-devbox_us-central1_autopilot-cluster-1
contexts:
  - context:
      cluster: gke_security-devbox_us-central1_autopilot-cluster-1
      user: gke_security-devbox_us-central1_autopilot-cluster-1
    name: gke_security-devbox_us-central1_autopilot-cluster-1
current-context: gke_security-devbox_us-central1_autopilot-cluster-1
kind: Config
preferences: {}
users:
  - name: gke_security-devbox_us-central1_autopilot-cluster-1
    user:
      auth-provider:
        config:
          access-token: <access token>
          cmd-args: config config-helper --format=json
          cmd-path: gcloud
          expiry: "2022-12-06T01:13:11Z"
          expiry-key: "{.credential.token_expiry}"
          token-key: "{.credential.access_token}"
        name: gcp
```

### `container.roles.escalate` | `container.clusterRoles.escalate`

**Kubernetes** 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.bind`

**Kubernetes** 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.update`

All 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 GC**P (by default the compute SA is used).

### `container.secrets.get` | `container.secrets.list`

As [**explained in this page**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#listing-secrets)with these permissions you can **read** the **tokens** of all the **SAs of kubernetes**, so you can escalate to them.

### `container.pods.exec`

With 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.portForward`

As **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.createToken`

Because 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.update`

These 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**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#malicious-admission-controller).

{{#include ../../../banners/hacktricks-training.md}}



