{
  "id": "service-account/impersonate",
  "description": "Allows impersonating a service account to act with its permissions",
  "platforms": {
    "aws": [
      {
        "grant": {
          "actions": ["sts:AssumeRole"]
        },
        "binding": {
          "stack": {
            "resources": ["arn:aws:iam::${awsAccountId}:role/${stackPrefix}-*"]
          },
          "resource": {
            "resources": ["arn:aws:iam::${awsAccountId}:role/${stackPrefix}-${resourceName}"]
          }
        }
      }
    ],
    "gcp": [
      {
        "grant": {
          "permissions": ["iam.serviceAccounts.getAccessToken"]
        },
        "binding": {
          "stack": {
            "scope": "projects/${projectName}",
            "condition": {
              "title": "Service account impersonation access",
              "expression": "resource.type == 'iam.googleapis.com/ServiceAccount' && resource.name.startsWith('projects/${projectName}/serviceAccounts/${stackPrefix}-')"
            }
          },
          "resource": {
            "scope": "projects/${projectName}/serviceAccounts/${stackPrefix}-${resourceName}@${projectName}.iam.gserviceaccount.com"
          }
        }
      }
    ]
    // Note: Azure is intentionally not included here. Azure impersonation works differently -
    // the managed identity must be attached to the workload (Container App, VM, etc.) at provisioning time.
    // The workload can then request tokens for any attached identity by specifying its client_id.
    // No additional permissions are needed at runtime - the attachment itself grants the access.
  }
}
