> For the complete documentation index, see [llms.txt](https://docs.forestall.io/forestall/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/forestall/introduction/glossary/gcp-glossary.md). # GCP Glossary The glossary explains how cloud identities, roles, and configurations are classified, how high-impact identities are identified, and how privilege levels affect security within GCP environments. *** ### GCP Objects Forestall ISPM analyzes the following identity and configuration objects within GCP environments. * Organizations * Folders * Projects * Users * Groups * Service Accounts * Service Account Keys * Devices * Roles * Principals * Certificates * KMS Keys * Secrets * Virtual Machines * Workforce Identity Pools * Workforce Providers * Workload Identity Pools * Workload Providers *** ### Tier 0 (GCP) #### What "Tier 0" Means in GCP Tier 0 identities in GCP represent control over the entire GCP organization and its identity and resource control plane. Any identity, role, or configuration that can manage authentication, authorization, IAM role assignments, or security policies at the organization level is considered Tier 0. Compromise of a Tier 0 identity can result in full control over users, groups, service accounts, projects, folders, and cloud resources within the organization. For this reason, Tier 0 identities must be tightly protected and managed only through secure administrative access by the most-trusted administrators. #### Which GCP Objects Are Always Tier 0 The following GCP objects are always considered Tier 0 due to their ability to control the organization-wide identity and security boundary. * GCP Organization node * Organization Administrator role (`roles/resourcemanager.organizationAdmin`) * Organization Policy Administrator role (`roles/orgpolicy.policyAdmin`) * IAM roles with organization-wide scope * Service accounts with organization-level IAM bindings #### How GCP Objects Get Their Tier In GCP environments, the tier of an object is determined by the scope of IAM permissions, role bindings, and relationships to Tier 0 identities. Objects that are not inherently Tier 0 can become Tier 0 or Privileged through direct or indirect IAM role bindings, delegated administrative permissions, or control over Tier 0 identities. Forestall determines the effective tier of GCP objects by analyzing IAM role scopes, binding chains, and privilege relationships during GCP scans. *** ### Privileged (GCP) Privileged objects in GCP are identities, roles, or configurations that have high-impact permissions over GCP resources or security controls, but do not represent full organization-level control. These objects can significantly affect users, service accounts, projects, folders, or security settings and may be leveraged to indirectly compromise Tier 0 identities. Forestall marks the following types of objects as Privileged in GCP environments: * GCP roles with high-impact administrative permissions at the project or folder level * Users or service accounts assigned to roles that manage IAM policies, service accounts, or security configurations * Service accounts with broad project-level or folder-level permissions * Objects with delegated permissions that can modify privileged identities or IAM policies * Service Account Keys associated with privileged service accounts *** ### Unprivileged (GCP) Unprivileged objects in GCP are identities and roles that do not have elevated administrative permissions and cannot directly or indirectly compromise Tier 0 or Privileged objects. These objects typically have limited scope and impact within the GCP environment. All GCP objects that are not classified as Tier 0 or Privileged are considered Unprivileged by Forestall. *** ### Everyone-Like (GCP) Everyone-Like objects in GCP are identities, groups, or IAM bindings that implicitly or broadly include a large portion of the organization, resulting in wide-reaching access or impact. These objects do not necessarily grant high privileges on their own, but their broad membership or scope can significantly increase the attack surface and amplify the impact of misconfigurations or privilege escalation paths. Forestall uses the Everyone-Like classification to identify GCP objects that represent broad or implicit access across the organization. Common examples include bindings granted to `allUsers`, `allAuthenticatedUsers`, or large Google Groups that span the entire organization. *** ### Shadow Admin (GCP) Shadow Admin objects in GCP are identities, roles, or configurations that are not explicitly classified as Tier 0 or Privileged, but can indirectly compromise Tier 0 identities or gain high-impact control through IAM role bindings, delegated permissions, or privilege relationships. These objects may enable privilege escalation paths that result in organization-level impact without being immediately obvious as administrative identities. Forestall identifies GCP Shadow Admins by analyzing IAM role scopes, permission delegations, and indirect control paths within the GCP environment. *** ### GCP Object Classifications #### GCPOrganization The GCP Organization is the root node of the resource hierarchy. It inherently represents Tier 0, as any identity that controls the organization has full authority over all folders, projects, and resources beneath it. *** #### GCPFolder GCP Folders are used to group projects and apply IAM policies at an intermediate level. A folder can become Tier 0 or Privileged if it contains critical projects or if IAM roles granted at the folder level propagate high-impact permissions to child resources. *** #### GCPProject GCP Projects are the primary boundary for resource deployment and IAM scoping. A project can become Tier 0 or Privileged depending on the sensitivity of the resources it contains and the scope of IAM bindings applied to it. *** #### GCPUser GCP Users are human identities (Google accounts or Workspace users) that authenticate to GCP services. A user's tier is determined by the IAM roles bound to them at the organization, folder, or project level, and by their relationships to other privileged identities. *** #### GCPGroup GCP Groups are Google Workspace groups used to manage collections of users and service accounts for IAM policy bindings. A group's effective privilege level is determined by the IAM roles assigned to it and the scope of those bindings. Groups with organization-wide membership or broad IAM permissions can be classified as Everyone-Like. *** #### GCPServiceAccount GCP Service Accounts are non-human identities used by applications and workloads to authenticate to GCP services. A service account's tier is determined by the IAM roles bound to it, the projects it belongs to, and whether it can be impersonated by other identities. Service accounts with organization-wide or high-impact permissions are classified as Privileged or Tier 0. *** #### GCPServiceAccountKey GCP Service Account Keys are credentials associated with service accounts, used for authentication outside of GCP-native contexts. A key inherits the privilege level of its parent service account. Keys associated with Tier 0 or Privileged service accounts represent a significant risk if exposed, as they can be used to authenticate as the service account from any environment. *** #### GCPRole GCP Roles define sets of permissions that are granted to identities via IAM bindings. A role's classification depends on the permissions it includes and the scope at which it is applied. Custom roles with high-impact permissions — such as the ability to manage IAM policies, impersonate service accounts, or administer organization-level resources — are classified as Privileged or Tier 0. Predefined roles with organization-wide administrative capabilities are always considered Tier 0. *** #### GCPDevice GCP Devices are endpoints registered in the Google Workspace environment and associated with user accounts. A device's risk classification is based on its management state, encryption status, and the privilege level of the users associated with it. Unmanaged or unencrypted devices linked to privileged users represent an elevated security risk. *** #### GCP Principal GCP Principals represent an identity or set of identities (such as a federated user, service account, or matched principal set) that can be granted IAM roles directly. A principal's tier is determined by the roles bound to it and, for federated principals, by the scope of the subject it matches. A principal that represents an entire workforce or workload identity pool (e.g., a wildcard `principalSet` subject) is treated as Everyone-Like, since a role granted to it is effectively granted to every identity in the pool. *** #### GCP Certificate GCP Certificates, managed through Certificate Manager, establish TLS/SSL trust for services and workloads. A certificate's classification depends on the sensitivity of the services it secures and its managed status. Certificates nearing expiration or supporting privileged or externally-facing services carry elevated risk, as their compromise or lapse can undermine trust in those services. *** #### GCP KMS Key GCP KMS Keys are cryptographic keys managed through Cloud Key Management Service, used to encrypt and decrypt sensitive data, secrets, and disks. A key's tier is determined by the sensitivity of the data it protects, its accessibility (e.g., public IAM bindings), and whether automatic key rotation is enabled. Publicly accessible KMS keys or keys without rotation enabled represent a significant credential security and data protection risk, and keys protecting organization-wide resources may be classified as Tier 0. *** #### GCP Secret GCP Secrets, managed through Secret Manager, store sensitive values such as credentials, API keys, and tokens. A secret's classification depends on the sensitivity of the material it holds and the privilege level of the identities that can access it. Secrets that grant access to privileged service accounts, keys, or infrastructure are classified as Privileged, since their exposure can directly enable further compromise. *** #### GCP Virtual Machine GCP Virtual Machines are Compute Engine instances that run workloads within a project. A VM's tier is influenced by the service account attached to it, whether OS Login and project-wide SSH key blocking are enabled, and the sensitivity of the workloads it runs. VMs using the default service account, lacking OS Login, or permitting project-wide SSH keys carry elevated privilege escalation and credential security risk. *** #### GCP Workforce Identity Pool GCP Workforce Identity Pools allow external workforce (human user) identities from third-party identity providers to access Google Cloud resources without creating Google identities for each user. A pool's tier depends on the scope of IAM roles granted to its principals and principal sets; pools with roles bound at the entire-pool level (rather than to specific identities) are considered high-risk, as they implicitly grant access to every federated user. *** #### GCP Workforce Provider GCP Workforce Providers (e.g., SAML or OIDC providers such as Entra ID) define how external workforce identities federate into a Workforce Identity Pool. A provider's risk is determined by whether it enforces an attribute condition restricting which external identities may authenticate. Providers with no attribute condition can allow any identity from the external IdP to federate in, and are treated as a high-risk, Everyone-Like access path. *** #### GCP Workload Identity Pool GCP Workload Identity Pools allow external workload (non-human, e.g., CI/CD systems or external services) identities to access Google Cloud resources without exported service account keys. A pool's tier depends on the scope of IAM roles granted to its principals and principal sets, following the same logic as Workforce Identity Pools but for machine identities. *** #### GCP Workload Provider GCP Workload Providers (e.g., OIDC or AWS providers) define how external workload identities federate into a Workload Identity Pool. As with Workforce Providers, a provider's risk is determined by whether it enforces an attribute condition; providers without one may allow any external workload identity presenting a token from the trusted issuer to federate in and assume access within the organization.