AWS
Google CloudOverview
Identities that can be assumed or impersonated by external principals create a direct cross-tenant access path.
What this control checks
- AWS IAM roles with broad trust relationships.
- GCP service accounts with external access.
Why this matters
External trust should be explicit, minimal, and tightly controlled.
Remediation guidance
AWS remediation
- Edit role trust policy and remove broad principals.
- Allow only explicit trusted role/account ARNs.
- Add restrictive conditions for third-party use cases.
aws iam update-assume-role-policy --role-name <role-name> --policy-document file://trust-policy.json
GCP remediation
- Review service account IAM policy bindings.
- Remove external members that are not approved.
gcloud iam service-accounts get-iam-policy <sa>@<project-id>.iam.gserviceaccount.com
gcloud iam service-accounts remove-iam-policy-binding <sa>@<project-id>.iam.gserviceaccount.com --member="user:<[email protected]>" --role="roles/iam.serviceAccountTokenCreator"
References
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html
- https://cloud.google.com/iam/docs/service-account-permissions
Multiple Remediation Paths
AWS
SERVICE-WIDE (RECOMMENDED when many resources are affected): Deploy centralized guardrails and remediation using AWS Config Conformance Packs and (if applicable) AWS Organizations SCPs.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml
ASSET-LEVEL: Apply the resource-specific remediation steps above to only the affected assets.
PREVENTIVE: Add CI/CD policy checks (CloudFormation/Terraform validation) before deployment to prevent recurrence.
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- AWS Config Conformance Packs: https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html
- AWS Organizations SCP examples: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- AWS: deploy/adjust organization conformance packs and policy guardrails.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
AWS Roles allowing external access
Connectors
Covered asset types
Expected check: eq []
{
AWSRolesWithExternalAccess {
...AssetFragment
}
}Google Cloud Service Accounts allowing external access
Connectors
Covered asset types
Expected check: eq []
{
GCPServiceAccountsWithExternalAccess{
...AssetFragment
}
}
