Disable

gcloud resource-manager org-policies disable-enforce [–folder | –organization | –project ]

</details>

'n Python-skrip vir hierdie metode kan gevind word [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).

### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`

Gewoonlik is dit nie moontlik om 'n service account van 'n ander project aan 'n resource te koppel nie, omdat daar 'n beleidsbeperking afgedwing word met die naam **`iam.disableCrossProjectServiceAccountUsage`** wat hierdie aksie verhinder.

Dit is moontlik om te verifieer of hierdie beperking afgedwing word deur die volgende opdrag uit te voer:

<details>
<summary>Verifieer cross-project service account-beperking</summary>
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
--project=<project-id> \
--effective

booleanPolicy:
enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage

Dit keer dat ’n aanvaller die toestemming iam.serviceAccounts.actAs kan misbruik om ’n service account van ’n ander projek te imiteer sonder die nodige verdere infrastruktuur-toestemmings om byvoorbeeld ’n nuwe VM te begin, wat tot privilege escalation kan lei.

Egter kan ’n aanvaller met die toestemmings orgpolicy.policy.set hierdie beperking omseil deur die constraint iam.disableServiceAccountProjectWideAccess uit te skakel. Dit laat die aanvaller toe om ’n service account van ’n ander projek aan ’n resource in sy eie projek te koppel, en sodoende sy voorregte effektief te verhoog.