# Intermediate Entities Early Access: *System* search mode for all providers and *Path Summaries* are support-enabled features. Contact the Veza customer success team to enable them. This document provides some example usages of *Required* and *Excluded* related entity types, applying *Attribute Filters* on intermediate entity properties, and *System* search mode. The techniques and concepts are generally applicable to role-based platforms such as Microsoft Azure and Google Cloud. * [Background](#background) * [Required entities](#required-entities) * [Role-based access control](#role-based-access-control) * [Query modes](#query-modes) * [Filter users by group membership or role binding](#filter-users-by-group-membership-or-role-binding) * [Search directly-assigned and inherited policies](#search-directly-assigned-and-inherited-policies) * [Review users with "direct access" (not managed by group)](#review-users-with-direct-access-not-managed-by-group) * [Filter by group membership](#filter-by-group-membership) ### Background #### Required entities Queries can filter results based on relationships to other entities, by specifying *required* or *excluded entity types*. Adding a "required" or "excluded" entity allows for additional constraints on those entities, such as attribute filters on an intermediate policy or group `name`. Used in Search and Workflows these filters can help understand and review role-based access controls for a range of cloud platforms and data systems. #### Role-based access control Authorization within Google Cloud has several characteristics that differ from how other providers such as Amazon implement identity and access management (IAM): * A role-via-binding IAM model separates the two components of permissions and resources, and allows them to be arbitrarily paired. * Policies granting resource access can be directly applied to resources, *OR* applied at the organization, project, or folder level, and can apply hierarchically. Permissions can apply directly to a user, or to a group the user is a member of. * In this model, Veza *Effective Permissions* calculations for search results represent all user or group, role, and policy combinations that cumulatively result in access to a resource. #### Query modes *System* [query mode](/4yItIzMvkpAvMVFAamTf/features/search/query-mode.md) is well-suited for querying and visualizing authorization involving intermediate entities such as roles, policies, and groups. Enabling *System* query mode enables search and constraints for entities such as *Google Role Binding*. To offer reviewers information and context about roles, policies, and groups during Google access reviews, operators can customize a [summary column](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/presentation-options.md) when creating a certification, with extra details about *required* entity types. * To apply attribute filters on properties of related entities, specify them for *Required entities*. *Excluded* entity types cannot be Workflow *Summary* entities, and vice versa. * Note that in the default *Effective* search mode, the Access Graph *Explain Effective Permissions* action will show the raw authorization relationships that constitute the effective permission calculation. However, constraints cannot apply to some intermediate entities in effective mode. ### Filter users by group membership or role binding The role assigned to an identity in a Google organization define the actions it can take on resources and settings. To make informed decisions about an individual identity's level of access within an organization, it is important to understand what roles govern their assigned permissions. Access Graph, Query Builder, and Workflows can use *System* mode to search and filter on intermediate authorization entities. These entities can include types such as Role Bindings and Group Assignments, connecting the source and destination entities. ![Google Users to Google Project, with system mode enabled.](/files/ZEYvoBI9nCcccTlO04mR) > You can create certifications and rules that audit the owner, manager, or member status of Google Users and resources by adding a filter on the `name` attribute of system mode "Google Group Membership" required entity. System mode also allows you to *exclude* or *require* intermediate entities such as policy bindings. ![Attribute filter on Google Role Binding](/files/fvy4U6ZRbxwA5kuv9LEY) ### Search directly-assigned and inherited policies Policies applied at the Google Organization, Folder(s), and Project levels are hierarchical (in that order), and inherited by resources lower in the hierarchy. Alternately, permissions can result from a policy attached directly to the resource it grants access on. You can use Veza to identify cases a *directly-assigned* policy allows permissions on a resource. You can also review access governed by policies *inherited* from a upper-level resource in the organization’s resource hierarchy: To review access granted by a policy attached to the resource it applies to, the workflow query must exclude all resource types with hierarchical precedence over the destination resource in the organization. This includes any superior organizations, folders, or projects. For example: * For access granted by lower-level policy: exclude entity types *Google Folder* and *Google Organization* * For folder permissions inherited from Organization or Folder(s): exclude entity types *Google Project* To create a query that returns only results with permissions from directly-applied policies: * Create a workflow, and enable *system* mode * Specify the source and destination (*Google User* to *Google Storage Bucket*) * Expand *Advanced Options* > *Exclude Entity Types* * Add *Google Organization, Google Folder, Google Project* * Finish customizing the workflow and save it When generated, the certification will review only users whose authorization path does not include organization-level, folder-level or project-level permissions. To query for resource access inherited at the organization, folder or project level: * Create a workflow, and enable *system* mode * Specify the source and destination (*Google User* to *BigQuery Service*) * Expand *Advanced Options* > *Require Entity Types* * Add *Google Project* * Finish customizing the workflow and save it Certifications on this workflow will include only users whose authorization path derives from organization-level, folder-level, or project-level permissions. ### Review users with "direct access" (not managed by group) Human and non-human identities are typically granted access by a group and role representing their department or function. Search and Workflows can be fine-tuned to identify users granted discretionary access to resources, but are not assigned to an appropriate group. For example: * Search direct User to Role access: exclude *Google Group* entities to return results with paths that do not contain any groups. * Search access that is (or is not) managed by a specific group or policy by setting attribute filters on group or policy. If expected entity types are not shown when applying an attribute filter, try changing the query to *system* mode. By *excluding* intermediate entity types, you can generate [alerts](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md) for user with "direct access" to a resource. Workflow [path summaries](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/presentation-options.md) aid in showing whether the result involves an intermediate group assignment. ### Filter by group membership Google Users can be owners, managers, or members of their assigned groups. You can customize certifications to only review users granted access by means of a specific intermediate role-based access control entity, such as a `contractors` group. Adding a filter on the *Google Group Membership* `Membership Type` will constrain results by group membership (`Owner`, `Manager`, or `Direct Member`). To search for all users with a given group membership type: 1. Start a query in *system* mode 2. Pick *Google User* for the source entity category to search 3. Pick the resource (such as *Google Project* or *Service*) to review access to 4. Pick *Require Entity Types* > *Google Group Membership* 5. Add a constraint on the "Membership Type" attribute ("Owner", "Manager", or "Direct Member") Two methods are useful for finding specific types of members for a particular group. For example, to find all Managers of the "Developers" group: * Single constraint on *Group Membership* entity `name` = "\ \" (Developers Managers) * Two constraints: *Group Membership* `membership_type` = "Manager", *Group* entity "name" = "\"(Developers) To show group names and membership types for additional context for certification reviewers, add *Google Group Membership* to the [summary](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/presentation-options.md#summary-entities) when creating the workflow. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/search/intermediate-entities.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.