Notes & Supported Entities

Supported entity types and more information about the Veza-AWS connector.

Veza integrates with AWS to parse service and resource metadata using native API calls. You can enable the read-only connection via an IAM user, an assumed IAM role, or using an Insight Point running on EC2.

Veza creates entities in the data catalog to represent the discovered resources and identities, including tags and attributes applied within AWS. To gather granular metadata for database services such as RDS, Veza requires additional permissions to connect as a local user and execute queries when data APIs aren't available.

Veza finds the cross-service connections between the discovered entities, and calculates the effective permissions and authorization paths, including the cumulative effects of permission boundaries, service control policies, group memberships and hierarchical policy statements. These relationships can be searched on the Authorization Graph, or audited using Workflows or the Query Builder.

Beyond relationships within and between AWS accounts, Veza also supports identify federation to show authorization for external Okta, AzureAD, or custom application/IdP users and groups.

Adding accounts with Veza APIs

You can use the management API to configure AWS connectors programmatically.

For example:

curl -X POST '{baseurl}/api/v1/providers/aws
-d  {
  "values": [
    {
      "name": "AWS-Org",
      "type": "AWS",
      "data_plane_id": "a2e32a80-9d64-4725-b4a9-8de6ffd0682b",
      "status": "SUCCESS",
      "account_id": "123456789010",
      "credentials_type": "ASSUME_CUSTOMER_ROLE",
      "access_key_id": null,
      "assume_role_name": "veza-connector",
      "assume_role_external_id": "0477997275",
      "regions": [],
      "db_user": "veza_db_user",
      "services": [],
      "redshift_database_allow_list": [],
      "redshift_database_deny_list": [],
      "rds_database_allow_list": [],
      "rds_database_deny_list": [],
      "s3_bucket_allow_list": [],
      "s3_bucket_deny_list": []
    }
  ]
}

Note that by default, all regions and services are extracted. Allow/deny lists can contain string lists (including wildcards) of resources names to ignore.

API Rate Limits

Following best practices for AWS client applications, Veza implements an exponential backoff mechanism for requests (see the AWS documentation on Error Retries and Exponential Backoff for more information). This should prevent hitting endpoint rate limits, and provide ample room for other services to consume the same APIs.

By default, exponential backoff is configured for up to 10 attempts, with a max wait of 300 seconds.

Built-In Insights

Veza includes an ever-growing collection of queries for detecting AWS configuration anomalies, over-privileged entities, and other risks. These assessments are included in such Reporting categories as AWS IAM Analysis and Data Advanced Configurations, or can be retrieved by filtering the Saved Queries page.

Searching for AWS Entities

The Authorization Graph includes some additional support for searching AWS entities:

• To see the native AWS permissions for an Effective Permission, select an ungrouped EP node and choose Explain Effective Permissions on the actions sidebar

• To view an AWS IAM policy, select a Policy node and choose Show JSON Document from the actions sidebar

• AWS IAM Role relationships may be nested (a role assignment can imply membership in another). When this is the case, an icon will indicate that the node has a hierarchical relationship. Choose Show Hierarchy to open a detailed view. Entities will have a hierarchical_level to enable search on nested nodes.

• When multiple AWS accounts are connected, entities with the same name (such as built-in IAM roles) are numbered for differentiation. Toggle the AWS Account Label search option to add additional color-coding by account name.

• You can highlight authorization paths available via role assumption using the Entities of Interest graph search option.

Supported Entities

See the sections below for more information about the supported entity types within AWS, along with advanced configuration and search options:

Identity and Access Management

The following entity types are discovered using the provided IAM policy:

• AWS Accounts

• IAM Groups

• IAM Users

• IAM Roles

• IAM Policies

• IAM Permissions

AWS IAM Policy entities now show the Permissions Boundary Usage Count, enabling queries on unused policies with no relationship to any principals.

Several additional services and data sources are discovered automatically, while others require additional configuration (described in this document).

Organizations and Organizational Units

When an AWS organization management account is connected, metadata is discovered for the additional entity types:

• AWS Organization Unit

• AWS Organization Account

you can track org unit accounts not yet configured for discovery using the assessments AWS Accounts that are part of an organization but not managed, Total AWS Organizational Units & Total AWS Accounts that are configured and managed.

Each AWS Organization and its SCPs are handled as an individual data source on the Configuration and Identity Data Entities panels. Relationships are parsed for organizational units, between org units to org accounts, and org accounts to the corresponding AWS accounts.

Relational Database Service (RDS)

The default policy includes permission to discover RDS services, instances, and clusters. To get database-level metadata, users, and privileges, Veza will need to be able to execute database queries as a local Postgres or MySQL user.

• RDS Service

• RDS Instance

• RDS Cluster

• RDS Cluster Instance

RDS MySQL

With a local MySQL user configured, additional entities are parsed:

• RDS MySQL Database

• RDS MySQL Table

• RDS MySQL Instance

• RDS MySQL Role

• RDS MySQL Effective Permission

• RDS MySQL Role Instance

• RDS MySQL Local User

• RDS MySQL Local User Instance

• RDS MySQL Service

RDS PostgreSQL

The following entities are discovered using a local Postgres user to run queries:

• RDS Postgres Database

• RDS Postgres Schema

• RDS Postgres Instance

• RDS Postgres Service

• RDS Postgres Table

• RDS Postgres Group

• RDS Postgres Effective Permission

• RDS Postgres Local User

Amazon Redshift

The default policy only includes API permissions to get authorization metadata for Redshift clusters. To connect to Redshift databases for full discovery, a local Redshift user with the redshift:GetClusterCredentials IAM privilege must be available.

• Redshift Cluster

• Redshift Database

• Redshift Schema

• Redshift Effective Permission

• Redshift Local User

• Redshift Database Instance

• Redshift Group

• Redshift Table

• Redshift Service

S3 Buckets

Using the recommended policy, Veza will parse :

• S3 Service

• S3 Bucket

• S3 Bucket Policies

• S3 Bucket Policy Statement

As of release 2022.2.1, effective permissions to S3 now consider object-level permissions granted via IAM policy. Actions granted via *, bucketname, and bucketname/* now extend to the appropriate S3 object(s) and can be reviewed in detail by clicking Explain Effective Permissions from the Graph actions sidebar.

Access Points are not yet supported.

Note that S3 bucket objects can have individual Access Control Lists. Since Veza doesn't parse individual bucket objects, object-level permissions may not be authoritative for buckets allowing ACLs. Buckets with ACLs enabled should be monitored as part of secure operational practice, which can be accomplished using the system query "S3 buckets with potential public ACLs."

Key Management Service (KMS)

Veza natively supports AWS Key Management Service (KMS) using the recommended IAM policy. You can search to find Customer Master Keys (CMKs) and view cross-service relationships between IAM roles and policies, KMS keys, and data sources.

• KMS Service

• KMS Customer Managed Key (CMK)

• KMS Policy

• KMS Policy statements

• KMS Permissions

• KMS Customer Managed Key Permissions

In order for a CMK to be discoverable, its Key Policy must have IAM permissions enabled, or grant the Veza AWS IAM principal directly. See KMS for more information.

DynamoDB

DynamoDB discovery doesn't require a local user and is enabled in the default policy:

• DynamoDB Service

• DynamoDB Table

• DynamoDB Secondary Index

• DynamoDB Stream

See DynamoDB for more information.

Elastic MapReduce

The default policy includes permissions to get:

• EMR Service

• EMR Cluster

• EMR Node

• EMR Studio

• EMR Notebook Execution

The EMR service to discover must use EC2 (EMR on EKS isn't yet supported). See EMR for more details.

EC2

The default policy includes permissions to gather entities for:

• EC2 Service

• EC2 VPC

• EC2 Security Group

• EC2 Instance

As of Veza 2021.2.1, EC2 discovery is supported for up to 1000 instances per AWS account.

Unsupported Conditions in Policy Statements

Veza does not currently support all AWS policy conditions operators and keys.

The unsupported conditions include ones that are difficult to parse or meaningless in Veza's graph representation, such as DateGreaterThan:aws:CurrentTime. However, unsupported conditions CAN have a meaningful impact on the actual access granted to principals shown in Graph.

When Veza detects an unsupported condition, the boolean property Unsupported Condition is set to True for the corresponding Policy Statement and Permission nodes.

This property can be included in an Attribute Filter to display query results that are or are not impacted by unsupported conditions.