Amazon Web Services

Understand, manage, and control AWS IAM identity and entitlements

There are several ways to configure Veza to connect to Amazon Web Services (AWS). The method you choose depends on your security requirements and the data sources in your environment. Typically, Veza should connect by assuming an IAM role.

If you need to discover non cloud native data sources within an AWS account, you should use an Insight Point for a secure authentication. As a less secure but easy-to-establish connection method, you can optionally connect to AWS as an IAM user.

If possible, you should integrate your primary AWS Organization account, to enable full extraction of Service Control Policies (SCPs) and Organizational Units (OUs). When a primary OU is configured, other accounts not yet connected to Veza can still be audited using the Veza Entity Catalog.

After establishing an AWS Control Tower Landing Zone, you can Automatically Add New AWS Accounts in your AWS Organization to Veza. Once enabled, Veza will register accounts whenever they are enrolled or provisioned into an OU governed by AWS Control Tower.

To programmatically add all current accounts in an Organization with AWS CloudFormation, see Add existing AWS accounts

1. Create a Veza-AWS connector policy

Whether connecting using an IAM role or IAM user, you will need to create an IAM policy that grants Veza permission to make read-only API calls.

If your organization uses AWS CloudFormation with Terraform, you can use the following configuration to automate creation of a new policy and role:

6KB

AWS_Terraform_Veza.tf

To create the role manually using AWS IAM Console, choose Policies > Create and select the JSON tab. Copy the policy shown below, and give it a name (for example veza-aws-connector):

Trust Policy for Veza 2023.12.4

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "STS",
      "Effect": "Allow",
      "Action": [
        "sts:GetCallerIdentity"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Tag",
      "Effect": "Allow",
      "Action": [
        "tag:GetResources"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SSO",
      "Effect": "Allow",
      "Action": [
        "sso:ListAccountAssignments",
        "sso:ListPermissionSets",
        "sso:ListAccountsForProvisionedPermissionSet",
        "sso:ListInstances",
        "sso:DescribePermissionSet",
        "sso:ListTagsForResource",
        "identitystore:DescribeUser",
        "identitystore:DescribeGroup",
        "identitystore:ListUsers",
        "identitystore:ListGroups",
        "identitystore:ListGroupMemberships"
      ],
      "Resource": "*"
    },
    {
      "Sid": "IAM",
      "Effect": "Allow",
      "Action": [
        "iam:ListPolicies",
        "iam:GetPolicy",
        "iam:GetPolicyVersion",
        "iam:ListRoles",
        "iam:ListGroupsForUser",
        "iam:ListAttachedRolePolicies",
        "iam:ListAttachedUserPolicies",
        "iam:ListUsers",
        "iam:ListAttachedGroupPolicies",
        "iam:ListGroups",
        "iam:GetUser",
        "iam:GetRole",
        "iam:ListUserPolicies",
        "iam:ListGroupPolicies",
        "iam:ListRolePolicies",
        "iam:GetUserPolicy",
        "iam:GetGroupPolicy",
        "iam:GetRolePolicy",
        "iam:ListSAMLProviders",
        "iam:GetSAMLProvider",
        "iam:ListAccessKeys",
        "iam:GetAccessKeyLastUsed",
        "iam:ListInstanceProfiles",
        "iam:ListAccountAliases",
        "iam:ListMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeVpcs",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Redshift",
      "Effect": "Allow",
      "Action": [
        "redshift:DescribeClusters",
        "redshift:GetClusterCredentials",
        "redshift-data:ExecuteStatement",
        "redshift-data:GetStatementResult",
        "redshift-data:DescribeStatement"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RDS",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBClusters",
        "rds:DescribeDBInstances",
        "rds-db:connect"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DynamoDB",
      "Effect": "Allow",
      "Action": [
        "dynamodb:ListTables",
        "dynamodb:DescribeTable",
        "dynamodb:ListStreams",
        "dynamodb:DescribeStream"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EMR",
      "Effect": "Allow",
      "Action": [
        "elasticmapreduce:ListClusters",
        "elasticmapreduce:DescribeCluster",
        "elasticmapreduce:ListNotebookExecutions",
        "elasticmapreduce:DescribeNotebookExecution",
        "elasticmapreduce:ListInstanceGroups",
        "elasticmapreduce:ListInstanceFleets",
        "elasticmapreduce:ListInstances",
        "elasticmapreduce:ListStudios",
        "elasticmapreduce:DescribeStudio"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketPolicy",
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation",
        "s3:GetBucketPublicAccessBlock",
        "s3:GetAccountPublicAccessBlock",
        "s3:GetBucketObjectLockConfiguration",
        "s3:GetEncryptionConfiguration",
        "s3:GetBucketLogging",
        "s3:GetBucketOwnershipControls",
        "s3:GetBucketRequestPayment",
        "s3:GetReplicationConfiguration",
        "s3:GetBucketWebsite",
        "s3:GetBucketPolicyStatus"
      ],
      "Resource": "*"
    },
    {
      "Sid": "KMS",
      "Effect": "Allow",
      "Action": [
        "kms:GetKeyPolicy",
        "kms:ListAliases",
        "kms:ListKeyPolicies",
        "kms:ListKeys",
        "kms:ListResourceTags",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Organization",
      "Effect": "Allow",
      "Action": [
        "organizations:DescribeOrganization",
        "organizations:DescribePolicy",
        "organizations:ListChildren",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListPolicies",
        "organizations:ListPoliciesForTarget",
        "organizations:ListRoots",
        "organizations:DescribeAccount"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Cognito",
      "Effect": "Allow",
      "Action": [
          "cognito-identity:DescribeIdentityPool",
          "cognito-identity:GetIdentityPoolRoles",
          "cognito-identity:ListIdentityPools"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Lambda",
      "Effect": "Allow",
      "Action": [
        "lambda:ListFunctions",
        "lambda:ListTags"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EKS",
      "Effect": "Allow",
      "Action": [
        "eks:ListClusters",
        "eks:DescribeCluster"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SecretsManager",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:DescribeSecret",
        "secretsmanager:ListSecrets"
      ],
    "Resource": "*"
    },
    {
    "Sid": "ECR",
    "Effect": "Allow",
    "Action": [
      "ecr:DescribeRegistry",
      "ecr:DescribeRepositories",
      "ecr:ListTagsForResource",
      "ecr-public:DescribeRepositories",
      "ecr-public:ListTagsForResource"
    ],
    "Resource": "*"
  },
  {
    "Sid": "CloudTrail",
    "Effect": "Allow",
    "Action": [
      "cloudtrail:GetTrail"
    ],
    "Resource": "*"
  }
  ]
}

This policy grants the attached principal (IAM user, role, or Insight Point EC2 Instance Profile) the privileges required to discover Organization, IAM, and tags metadata for the AWS account. It enables Veza to gather entities and authorization relationships for:

• S3 Buckets

• EC2 Instances

• RDS Databases (MySQL, PostgreSQL)

• Redshift Data Warehouses

Full extraction of Redshift and RDS requires a local user, which you will need to create and identify in the Veza access policy. For detailed instructions, see the setup guides for RDS MySQL, PostgreSQL, and AWS Redshift. More details are available on the Administration > Events panel when required permissions are unavailable, or credentials are invalid.

If you want to limit the extraction of specific AWS services and resources, you can do so using the "Edit Provider" menu or when adding the provider to Veza.

Service control policies (SCPs) and organization units (OUs) are discovered only when connecting to an AWS organization management account.

See Notes & Supported Entities for more details on the Veza-AWS connector and supported AWS services

2. Configure AWS discovery

Using an IAM role

AWS discovery using an assumed IAM role is the recommended method, especially when you don't need to discover additional, non-AWS-native data sources such as SQL databases or a Trino server. This method is reliable to implement, secure, and doesn't require additional steps to deploy an Insight Point to your cloud.

The steps below will enable a Veza AWS principal to assume a new role within your organization's AWS account for identity, resource, and authorization discovery.

You will need the ID of the Veza AWS account the role will apply to. To get this value:

1. Go to Veza Configuration > Cloud Providers > Add New

2. Add a new AWS account

   • Choose "Assume AWS IAM Role" as the Authentication Method.

   • You can use any values to populate the required fields, or use the actual account ID and region of the account you intend to configure.

   • Click "Save". A policy will display the Veza account ID, such as:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::[[ACOUNT_ID]]:role/[[TENANT_ID]]-insight-point"
         }
       }
     ]
   }

When creating the role in AWS, ensure that the principal AWS account and external ID values match the ones in the Veza-provided policy.

To create the AWS role, you will need administrator access to the AWS account. Complete the steps below using the AWS Management Console:

1. Navigate to IAM > Roles. Click “Create a role”

2. Select "AWS account" as the trusted entity, then choose "Another AWS account" as the trusted entity type. Provide the Veza AWS account ID retrieved using the steps above, or provided by your support team.

3. Check the box to require an External ID and give it a unique value. Copy down this External ID, and supply it when adding the AWS account to Veza using the New Cloud Provider wizard.

   • If you've already saved the Veza configuration, verify that the External IDs are the same.

4. Attach the IAM policy that will permit Veza to extract information about your AWS account.

5. Add optional tags, and give the role a name, description, and verify the trusted entity is correct.

Keep note of the new role's name, as it will be required to finish adding the provider under Veza Administration > Configuration.

Using an Insight Point

Connecting using a role or user will allow Veza to extract information for cloud-native data services using the appropriate APIs (such as AWS S3 and Redshift). However, for data services (for example SQL Server on EC2 Instance, or Oracle on EC2 Instance) that are not cloud-native or not available to external callers, Veza will need to establish connections directly to the entity using an Insight Point deployed to your cloud or local environment.

If you are connecting the account using an Insight Point, the AWS IAM policy must be updated to enable connection to the Veza ECR repository. Instead of attaching the policy to an IAM user, you will apply the policy to the role assigned to an Insight Point's EC2 instance profile.

See the full Insight Point instructions for detailed steps. You will need to deploy the Insight Point, and:

1. Create an AWS IAM role with EC2 as the trusted entity

2. Attach the Veza IAM policy to the role

3. Assign the role to your Insight Point instance profile.

Using an IAM user

From your AWS account dashboard, create an IAM user and attach the appropriate policy:

1. From the Add User interface, input a username (such as veza_connector), and select Programmatic Access as the Access Type

2. Select the policy you created earlier, and attach it to the new user

3. Once you have created the IAM user, copy the Access Key ID and Secret Access Key (you will need to repeat the previous steps if the key is lost).

3. Add the AWS account to Veza

To enable the provider as a new data source for Veza, navigate to Veza Configuration > Cloud Providers > Add New > AWS. Depending on the authentication method you select in Step 2 above, some different information will be required:

Assuming an AWS IAM Role: This **** is the recommended method for conducting discovery on AWS and allows Veza to assume an IAM role with the appropriate privileges.

• You will need to provide a display name for the AWS account, and the Account ID.

• For the Role Name, provide the name of the AWS IAM role you configured with the Veza IAM account as a trusted entity. Use the role name as it appears in the AWS UI (not the full ARN).

• The External ID must match the IAM role "trusted entity":

  • If you have created the AWS role, enter the External ID you provided from the AWS console.

  • If you haven't created the role at this point, copy the random identifier that appears here,and provide it as the External ID when adding Veza as the trusted entity in AWS.

When you click Save, a policy will display, showing the UUID that will be used as the external ID and the trusted AWS account number. If the values aren't the same, you should copy the policy on this screen, and update the Veza connector policy in AWS to match.

Using an IAM user Access Key ID / Secret Access Key: While user credentials are easy to generate and configure, this option should be considered less secure than IAM role assumption.

• Provide the AWS Access Key ID and Secret Access Key for the IAM user created in Step 2.

Using an Insight Point: Once you have deployed an Insight Point, you can opt to conduct discovery using the IAM role assigned to the Insight Point's EC2 instance profile.

• Provide a Name to display for the new provider, the AWS Account ID, and the local DB Username.

• From the Insight Point list, choose the Insight Point associated with the policy to use for discovery.

AWS configuration fields

Field	Details
Insight Point	Leave default unless using an Insight Point for discovery.
Authentication Method	See options below (assuming an AWS IAM Role is recommended).
Account ID	AWS account ID.
Role name	IAM role to assume.
External ID	Role external ID (if assuming an AWS IAM role).
Regions	Regions to discover (required).
AWS Access Key ID	For the IAM user to connect as (optional).
AWS Secret Access Key	For the IAM user to connect as (optional).
Extraction Policy Name	If provided, Veza will check that the specified policy exists in the AWS account and contains all required permissions.
Gather system tables	Option to gather additional RDS MySQL system tables sys, performance_schema, mysql, and information_schema.
DB User	Database local username for all RDS and Redshift extraction (optional).
Redshift DB User	Local username for Redshift extraction (optional).
RDS MySQL DB User	Local username for MySQL extraction (optional).
RDS PostgreSQL DB User	Local username for MySQL extraction (optional).

You can additionally set allow and deny lists to databases and buckets, or by choosing Limit Services Extracted and selecting the services to enable. See Limiting Extractions for more information.