Intermediate Entities
Filter graph, query, and workflow results by project role, policy hierarchy, group membership type, or indirect (non-group/role) access.
Last updated
Was this helpful?
Filter graph, query, and workflow results by project role, policy hierarchy, group membership type, or indirect (non-group/role) access.
Last updated
Was this helpful?
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.
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.
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.
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 Authorization 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.
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.
Authorization 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.
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
nameattribute of system mode "Google Group Membership" required entity. System mode also allows you to exclude or require intermediate entities such as policy bindings.
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.
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.
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:
Start a query in system mode
Pick Google User for the source entity category to search
Pick the resource (such as Google Project or Service) to review access to
Pick Require Entity Types > Google Group Membership
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 = "<Group> <Plural of MembershipType>" (Developers Managers)
Two constraints: Group Membership membership_type = "Manager", Group entity "name" = "<Group>"(Developers)
System 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 when creating a certification, with extra details about required entity types.
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 for user with "direct access" to a resource. Workflow aid in showing whether the result involves an intermediate group assignment.
To show group names and membership types for additional context for certification reviewers, add Google Group Membership to the when creating the workflow.
