🐛 Fix 21 incorrect GCP IAM permissions in auto-generated manifest#7080
🐛 Fix 21 incorrect GCP IAM permissions in auto-generated manifest#7080
Conversation
| "redis.instances.list", | ||
| "resourcemanager.folders.get", | ||
| "resourcemanager.folders.list", | ||
| "resourcemanager.folders.search", |
There was a problem hiding this comment.
resourcemanager.folders.search and resourcemanager.projects.search are not valid permissions
|
backupdr.dataSources.list -> Not a real permission. Should be backupdr.bvdataSources.list (backup vault data sources). |
|
Unable to complete the code review. Reason: The AI service is temporarily overloaded. Please retry in a few minutes. You can try |
|
Permission compute.networkFirewallPolicies.get is not valid |
Additional findings from role creation testingAfter testing role creation, 7 permissions were flagged as invalid. Two categories: Fixed: Wrong IAM permission names (this commit)
The REST API resource is Also added Not fixable in manifest: Org-level only permissionsThese 5 permissions are valid GCP IAM permissions but cannot be used in project-level custom roles — they require an organization-level custom role:
If consumers are creating project-level roles, these need to be excluded. We may want to add a |
The permission extraction heuristics produced several invalid GCP IAM permission strings. This fixes the generator and regenerates the manifest. **Service name prefix fixes (gcpServiceNameMap):** - cloudresourcemanager.* → resourcemanager.* (9 permissions) - sqladmin.* → cloudsql.* (2 permissions) - security.* → privateca.* (3 permissions) **Method-to-permission override table (new):** - accessapproval.accessApprovalSettings.get → accessapproval.settings.get - binaryauthorization.systemPolicy.get → binaryauthorization.policy.get - cloudkms.cryptoKey.get → cloudkms.cryptoKeys.get - cloudkms.iamPolicy.get → cloudkms.cryptoKeys.getIamPolicy - secretmanager.iamPolicy.get → secretmanager.secrets.getIamPolicy - secretmanager.secretVersions.list → secretmanager.versions.list - artifactregistry.iamPolicy.get → artifactregistry.repositories.getIamPolicy - serviceusage.service.get → serviceusage.services.get **Non-API method filtering (new skip list):** - monitoring.conditionAbsent.get, monitoring.conditionThreshold.get, monitoring.conditionMatchedLog.get, monitoring.conditionMonitoringQueryLanguage.get (protobuf getters, not real API calls) **Other generator fixes:** - Strip "Iter" suffix from gRPC iterator methods (iam.rolesIter.list → iam.roles.list) - Map REST "Aggregated" verb to "list" (dataflow.jobs.aggregated → dataflow.jobs.list) - Skip bare gRPC Get() calls with no resource qualifier (compute.compute.get) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ssions resourcemanager.folders.search and resourcemanager.projects.search are not valid GCP IAM permissions. The Search API requires the .list permission, so map the REST "Search" method to the "list" verb. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- backupdr.dataSources.list → backupdr.bvdataSources.list (backup vault data sources use the bvdataSources resource type) - Remove recommender.recommendations.list — not a real permission; the Recommender API uses type-specific permissions that can't be auto-derived from the code Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Queries the queryTestablePermissions IAM API at both project and org levels to catch all valid permissions, then compares against our generated gcp.permissions.json file and reports any invalid entries with fuzzy-match suggestions. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Separate permissions that can only be used in org-level custom roles (resourcemanager.folders.*, organizations.*, projects.list) into a dedicated org_level_permissions array. Add scope: "org" to matching detail entries. Update validation script to check both lists. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
vjeffrey
force-pushed
the
fix/gcp-permissions-validation
branch
from
decd71a to
a34dc39
Compare
![mondoo-code-review[bot]](https://avatars.githubusercontent.com/in/2834902?s=60&v=4){kind=small}
| @@ -0,0 +1,271 @@ | |||
| # Copyright Mondoo, Inc. 2024, 2026 | |||
There was a problem hiding this comment.
🔵 suggestion — The shebang (#!/usr/bin/env python3) on line 4 should be the very first line of the file for the OS to recognize it as a Python script when executed directly (./validate_permissions.py). Move the copyright/license comment block below the shebang line.
2 participants
Summary
Service name prefix fixes (gcpServiceNameMap):
cloudresourcemanager.*resourcemanager.*sqladmin.*cloudsql.*security.*privateca.*Method-to-permission overrides (new table):
accessapproval.accessApprovalSettings.getaccessapproval.settings.getbinaryauthorization.systemPolicy.getbinaryauthorization.policy.getcloudkms.cryptoKey.getcloudkms.cryptoKeys.getcloudkms.iamPolicy.getcloudkms.cryptoKeys.getIamPolicysecretmanager.iamPolicy.getsecretmanager.secrets.getIamPolicysecretmanager.secretVersions.listsecretmanager.versions.listartifactregistry.iamPolicy.getartifactregistry.repositories.getIamPolicyserviceusage.service.getserviceusage.services.getRemoved fake permissions:
monitoring.conditionAbsent.get,monitoring.conditionThreshold.get,monitoring.conditionMatchedLog.get,monitoring.conditionMonitoringQueryLanguage.get— protobuf getters, not API callsOther generator fixes:
Itersuffix from gRPC iterator methods (iam.rolesIter.list→iam.roles.list)Aggregatedverb tolist(dataflow.jobs.aggregated→dataflow.jobs.list)Get()calls with no resource qualifier (compute.compute.get)Test plan
make providers/build/gcpto confirm build succeedsgo run providers-sdk/v1/util/permissions/permissions.go providers/gcpproduces no diff🤖 Generated with Claude Code