Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Configuring the Veza integration for AWS
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 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 Access Graph.
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
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:
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):
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
To enable discovery of AWS IAM Identity Center entities, Trusted Access needs to be enabled for the service using either the AWS IAM Identity Center console or the AWS Organizations console:
From the AWS Organizations console, navigate to Services.
Choose AWS IAM Identity Center.
Choose Enable trusted access.
Check the box to show the option to enable trusted access without performing additional setup steps.
Type "enable" to confirm the change, then click to enable trusted access.
See Enabling trusted access with IAM Identity Center for detailed instructions.
Notes:
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 page and the integration details view 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 when adding the provider to Veza or using the "Edit Integration" menu.
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 integration and supported services
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:
Go to Veza Integrations > Add Integration
Select AWS and 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::[[ACCOUNT_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:
Navigate to IAM > Roles. Click “Create a role”.
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.
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.
Attach the IAM policy that will permit Veza to extract information about your AWS account.
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 on the Veza Integrations page.
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:
Create an AWS IAM role with EC2 as the trusted entity.
Attach the Veza IAM policy to the role.
Assign the role to your Insight Point instance profile.
From your AWS account dashboard, create an IAM user and attach the appropriate policy:
From the Specify User Details interface, input a user name (such as veza_connector) and click Next.
Select the policy you created earlier, and attach it to the new user.
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).
To enable the provider as a new data source for Veza, navigate to Veza Integrations > Add Integration > 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
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.
Discovery of DynamoDB Data Resources with Veza
Veza will automatically catalog DynamoDB resources for configured AWS accounts. All discovered DynamoDB tables, secondary indexes, and streams can be viewed in the data catalog, with cross-service effective permissions available in Authorization Graph search. DynamoDB insights are included in select Reports, or can be viewed using the Saved Queries panel.
To extract authorization metadata for DynamoDB, the IAM policy granting discovery and extraction permissions must include the following statement:
{
"Sid": "DynamoDB",
"Effect": "Allow",
"Action": [
"dynamodb:ListTables",
"dynamodb:DescribeTable",
"dynamodb:ListStreams",
"dynamodb:DescribeStream"
],
"Resource": "*"
}These permissions are included in the latest recommended policy; if you are upgrading from release
2021.6.xyou will need to update the policy attached to the Insight Point, IAM user, or IAM role used for discovery.
DynamoDB Table
DynamoDB Secondary Index
DynamoDB Stream
Identify overprovisioned and inactive users using CloudTrail logs.
ℹ️ Early Access: Monitoring for AWS is part of Access Monitoring, which must be enabled by our support team.
Veza gathers CloudTrail logs to audit user activity and generates Over Provisioned Scores (OPS) to show the percentage of unutilized access. This document provides steps to enable audit log extraction for an integrated AWS account.
Notes
Supported Entities: Veza generates over-provisioned scores for these relationships:
AWS IAM User
AWS S3 Bucket
AWS IAM User
AWS Secrets Manager Secret
AWS IAM User
AWS KMS Key
Okta Identity*
AWS S3 Bucket
Okta Identity*
AWS Secrets Manager Secret
Okta Identity*
AWS KMS Key
* Requires Activity Monitoring for Okta
Monitoring for multiple AWS accounts: To enable Activity Monitoring across several accounts in your organization, you'll need to repeat these steps for each integration for each account. In Query Builder results, OPS will be N/A for users from accounts where Activity Monitoring is not enabled.
The Activity Monitoring dashboard shows the dormant and over-provisioned AWS IAM Users, based on the resources they can access and the current Activity Monitoring time range. You can add constraints on OPS to Queries and Rules to enforce policies around user activity and actual resource usage.
Activity Monitoring Attributes: Veza creates properties to track different types of activity based on the resource type:
AWS IAM User:
Last Activity At: Timestamp of the most recent activity where the user was the principal, including activities in services not currently supported in Activity Monitoring (e.g., EC2 RunInstances)
AWS KMS Key:
Last Activity At: Timestamp of the most recent key usage of any type
Last Viewed: Timestamp of the most recent cryptographic operation that consumed key material (e.g., Decrypt)
You can enable monitoring for a single AWS account with an account-level trail, or create an organization trail containing events from several regions and accounts:
In AWS, create an organization or account-level trail for activity monitoring, or use an existing one. If you have many accounts where you want to enable monitoring, an organization trail is recommended for easier configuration.
In AWS, ensure the Veza service principal has authorization to discover cloud trails and read the trail in S3.
In Veza, enable audit logs for each AWS account integration. You can specify the same S3 bucket and organization trail (identified by its AWS resource name) for all integrations.
Enabling Activity Monitoring with AWS Control Tower For organizations that use AWS Control Tower to govern a multi-account AWS environment, AWS CloudTrail is configured by default, with two key accounts:
A Management account at the organization root, where Control Tower is configured.
A Log Archive account containing the S3 bucket where audit logs are stored.
In this scenario, you will need to configure Veza to extract audit logs from the log archive account, and skip extraction for the management account and other accounts in the organization:
Integrate the Log Archive account with Veza, if it is not already. To do so, use Cloud Formation for AWS Organizations, or add an AWS Account Integration.
Ensure that the Log Archive integration trust policy includes a policy for audit log extraction, allowing s3:ListBucket and s3:GetObject on the bucket and log files.
Enable audit logs for the Log Archive account integration. Enable the option "Extract for Organization" for this account.
Enable audit logs for all other accounts in the organization, choosing the "Skip Extraction" option for each account.
See the following steps for more details. Apply the appropriate policies based on your CloudTrail configuration:
Each account integration connects to a single Trail with event logs for the desired regions, accounts, and resources to gather activity data.
To use an existing Trail, search for CloudTrail on the AWS Console, and save the name and region for configuring the integration in Veza. The trail must include S3, Secret Manager, and IAM events.
If Veza cannot use an existing Trail, see Creating a Trail for the current instructions from AWS.
To enable Audit Log Extraction and Activity Monitoring for several AWS account integrations in Veza, you will need to update the integration trust policy within each AWS account to grant access to the S3 bucket and trail.
The AWS IAM Policy used by each Veza-AWS integration must grant permissions to read CloudTrail metadata, and list and retrieve objects in the S3 bucket and path where the CloudTrail logs are stored.
Follow the instructions below for organization or account trails, depending on your AWS architecture.
To update the integration trust policy:
On the AWS IAM Console, open the Policies page and locate the one used by the Veza-AWS Integration.
Search for the following SID, and create it if necessary:
{
"Sid": "CloudTrail",
"Effect": "Allow",
"Action": [
"cloudtrail:GetTrail"
],
"Resource": "*"
}This is required to discover if trails exist in the AWS account. Creating an AWS integration using the recommended policy includes the CloudTrail statement by default.
Enable access to account and organization-level cloud trails, using the examples below.
Save the changes to the policy.
Policy for audit log extraction
Update the integration IAM policy for the account where the organization trails resides to include the following statement. Depending on your environment, this could be the management account, or a dedicated log archive account. The following statement will allow Veza read access to retrieve logs from S3:
{
"Sid": "CloudTrail",
"Effect": "Allow",
"Action": [
"cloudtrail:GetTrail"
],
"Resource": "*"
},
{
"Sid": "CloudTrail-S3",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<bucket name>/AWSLogs/<organization id>/*",
"arn:aws:s3:::<bucket name>"
]
}To configure Activity Monitoring, use the organization trail ARN to enable audit logs for accounts in the organization where you want to enable monitoring. Choose "Extract for Organization" for the account where logs are stored. For other accounts in the organization, enter the trail ARN and select "Skip Extraction".
See Creating a trail for an organization for more on configuring organization trails in AWS.
To enable audit logs for multiple AWS accounts with account-level trails configured, each AWS account integration must have read permissions to discover trails and retrieve logs from S3.
See Creating a trail for your AWS account for more information about account-level trails.
Integration trust policy
For each account where you want to enable activity monitoring, update the integration policy to include the statement:
{
"Sid": "CloudTrail-S3",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<bucket name>/AWSLogs/<path to the files for the veza account>/*",
"arn:aws:s3:::<bucket name>"
]
}The path contains the AWS account ID. In the example above, <path to files for the Veza account> should have a unique value in each integration trust policy.
Key and bucket policies
You will need to update the S3 bucket policy or ACL, and possibly add a key policy, to ensure the Veza service principal (user or role) for each account integration has permission to read the files in S3. The required privileges are:
s3:ListBucket on the S3 bucket that CloudTrail logs into
s3:GetObject on the files logged by this trail in the bucket
kms:Decrypt on the KMS key (if a key is used to encrypt the trail)
Example bucket policy:
{
"Sid": "sid",
"Effect": "Allow",
"Principal": {
"AWS": "<ARN of the Veza user or role>"
},
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::<bucket name>/AWSLogs/<path to the files for the veza account>/*",
}
{
"Sid": "sid",
"Effect": "Allow",
"Principal": {
"AWS": "<ARN of the Veza user or role>"
},
"Action": [
"s3:ListBucket",
],
"Resource": [
"arn:aws:s3:::<bucket name>"
]
}Example key policy:
{
"Sid": "sid",
"Effect": "Allow",
"Principal": {
"AWS": "<ARN of the Veza user or role>"
},
"Action": "kms:Decrypt",
"Resource": "<the key ARN>"
}You can find the file and key location under “General details” on the trail details page.
Testing audit log permissions
To validate if an integration can access a trail in S3, try to download the file with the user or role that Veza assumes to access AWS:
aws s3api get-object --bucket <the S3 bucket for the trail> --key <any log file in the bucket> <path to save the file>In Veza, enable audit logs for each account where activity monitoring will be active:
On the Veza Integrations page, go to the Integrations page and click Enable Audit Logs next to the name of the AWS integration.
In the modal, enter the values from AWS:
The name of the Trail Veza will connect to, e.g., veza_s3_monitoring. For Organization trails, use the full ARN as the name, or when the trail is owned by an account other than the integration account.
The AWS region the CloudTrail service resides, e.g., us-east-2.
For organization trails, check "Extract for Organization" for the management account, and "Skip Extraction" for other accounts in the organization.
If your environment uses a log archive account for trail storage, check "Extract for Organization" for that account, and "Skip Extraction" for all other integrations.
For account trails, leave both checkboxes unchecked.
Save your changes. The integration will gather CloudTrail logs to calculate Over-Provisioned Access Scores during the next extraction cycle.
Repeat this step for each AWS integration where you want to enable Activity Monitoring.
Automatic Classification for AWS Key Management Service
Veza natively supports AWS Key Management Service (KMS) for all configured AWS accounts. You can use the Authorization Graph to display all Customer Master Keys (CMKs), and view cross-service relationships between IAM roles and policies, KMS keys, and data sources.
Any AWS tags and aliases are automatically extracted when discovering KMS keys. These can be viewed from the entity details, and used to filter search results.
As KMS discovery is enabled by default, no additional configuration is required. For more granular control over which AWS data resources are cataloged, you can select specific services for extraction by navigating to the Veza Integrations page, and choosing the "edit" option for the AWS account.
In order for a CMK to be discoverable, its Key Policy must have IAM permissions enabled, or grant the Veza AWS IAM principal directly. IAM policies are enabled by the default AWS KMS key policy, by a statement such as:
{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}To read authorization metadata for KMS, the IAM policy used by the Veza-AWS connector must include the following statement:
{
"Sid": "KMS",
"Effect": "Allow",
"Action": [
"kms:GetKeyPolicy",
"kms:ListAliases",
"kms:ListKeyPolicies",
"kms:ListKeys",
"kms:ListResourceTags",
"kms:DescribeKey",
"kms:GetKeyRotationStatus",
"kms:ListKeyRotations"
],
"Resource": "*"
}The last two permissions (kms:GetKeyRotationStatus and kms:ListKeyRotations) are required to show the AWS KMS CMK "Last Rotated At" attribute in Veza.
Creating a local user for gathering database-level metadata
When connecting an AWS account to Veza, the recommended IAM policy includes permissions to discover PostgreSQL instances and clusters on RDS. To gather additional metadata, Veza will need to be able to execute database commands as a local user, as described in this document.
AWS IAM DB Authentication must be enabled
You will need administrator privileges to create the local user, which will be used to connect at runtime
An Insight Point is recommended for RDS PostgreSQL discovery.
The Insight Point egress IP must be allowed in the RDS security group inbound rules.
Using an Insight Point is recommended when connecting to production environments. For testing purposes, you can use the internal Insight Point, assuming that firewall rules allow communication with Veza.
There are two options to allow Veza access to RDS PostgreSQL databases, depending on whether your instance configuration has revokedpublic privileges for the pg_catalog schema, as is a common security practice.
A) If you if you have not revoked the default public privileges on your schema, you only need to create the user and grant the rds_iam privilege:
CREATE USER [db_user] WITH LOGIN;
GRANT rds_iam TO [db_user];B) If you have revoked the default privileges from your schema, you should instead run the following command to create the user and grant select permissions for the required tables:
CREATE USER [db_user] WITH LOGIN;
GRANT rds_iam TO [db_user];
GRANT SELECT ON
pg_catalog.pg_user,
pg_catalog.pg_group,
pg_catalog.pg_namespace,
pg_catalog.pg_class,
pg_catalog.pg_database,
pg_catalog.pg_auth_members,
pg_catalog.pg_attribute,
pg_catalog.pg_roles,
pg_catalog.pg_trigger,
pg_catalog.pg_proc,
pg_catalog.pg_collation,
pg_catalog.pg_conversion,
pg_catalog.pg_type,
pg_catalog.pg_event_trigger,
pg_catalog.pg_extension,
pg_catalog.pg_foreign_data_wrapper,
pg_catalog.pg_foreign_table,
pg_catalog.pg_language,
pg_catalog.pg_largeobject_metadata,
pg_catalog.pg_operator,
pg_catalog.pg_opclass,
pg_catalog.pg_opfamily,
pg_catalog.pg_policy,
pg_catalog.pg_publication,
pg_catalog.pg_sequence,
pg_catalog.pg_foreign_server,
pg_catalog.pg_statistic_ext,
pg_catalog.pg_subscription,
pg_catalog.pg_tablespace,
pg_catalog.pg_ts_config,
pg_catalog.pg_ts_dict,
pg_catalog.pg_parameter_acl
TO [db_user];Verify that the RDS PostgreSQL DB User specified in the Veza IAM policy for the integration is the same as the local database user you create, for example:
"Resource": "arn:aws:rds-db:us-east-1:123456789:dbuser:*/<my_veza_db_user>"
Note that in the current release, the local username must be the same for all the RDS PostgreSQL resources to discover. You can specify this RDS PostgreSQL DB User name when configuring an AWS account.
The next time Veza connects to the AWS account, the database will be registered and appear under "Discovered Data Sources" on the Integrations > All Data Sources tab.
The following sections must be included in your Veza IAM policy. Update the bracketed values to contain your actual region, account ID, and the database username you specified when adding the AWS account.
{
"Sid": "RDS",
"Effect": "Allow",
"Action": [
"rds:DescribeDBInstances",
"rds:DescribeDBClusters"
],
"Resource": "*"
},
{
"Sid": "RdsDbConnect",
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": "arn:aws:rds-db:<region>:<account_id>:dbuser:<cluster-name>/<db_user>"
}Integrate multiple existing accounts in an Organization using AWS CloudFormation
AWS CloudFormation allows organizations to easily deploy AWS resources into existing accounts within the AWS Organization. Veza integrates with AWS CloudFormation to enable one-touch registration of AWS accounts with the Veza platform.
To control which AWS accounts will register with the Veza platform, the provided CloudFormation template can apply to the AWS Organization as a whole, specific Organizational Units within the AWS Organization, or specific AWS accounts.
The template will create the required IAM resources and a Lambda function responsible for registering and updating the managed account where it is deployed, and create a Veza AWS Integration for the account.
Veza's AWS Organizations integration is delivered as an AWS CloudFormation template that can be installed in the Organization's root account. The integration consists of three main infrastructure components that will be deployed to target accounts:
An AWS Lambda function:
This Lambda function executes when the AWS CloudFormation StackSet is first deployed and on any subsequent update or delete requests
This function interacts with Veza APIs to ensure that the target account is registered as a Cloud Provider in the organization's Veza platform and that its registration details are up-to-date
An IAM Role and Policy for the target account to allow Veza to assume an IAM Role with read-only access and discover the resources inside the account
An AWS Secrets Manager secret:
The Veza API key required for interacting with Veza APIs is encrypted and stored in the target account.
A strict IAM policy gives the AWS Lambda function access to this key for interactions with the Veza API The AWS Lambda function executes upon initial deployment of the AWS CloudFormation StackSet, as well as upon updates or deletes to the StackSet, allowing for centralized configuration control of the organization's AWS integrations.
Before deploying the Veza AWS Organizations integration, three pieces of data are required.
Make note of the URL used to connect to Veza (ex: https://example.vezacloud.com)
Generate an on the Veza platform for use by the CloudFormation template
Generate a UUID value for use as the ExternalId when Veza assumes the read-only IAM role
The following steps should be completed in the AWS Organizations root account by a user with permission to deploy CloudFormation StackSets.
Log into the AWS console, click Services, then search for and select CloudFormation.
In the left navigation bar, click StackSets.
In the right corner of the main pane, click Create StackSet.
In Step 1: Choose a Template, leave the default values selected and provide https://veza-controltower.s3.amazonaws.com/veza-aws-org-member-account.yaml in the Amazon S3 URL field.
In Step 2: Specify StackSet Details, provide the following:
StackSet Name: enter a display name for the CloudFormation StackSet
StackSet Description: enter an optional description of the CloudFormation StackSet
RemoveVezaIntegrationOnDelete: set to true to remove AWS accounts from the Veza platform if this StackSet is deleted (default: true)
VezaApiToken: paste in the API key generated on the Veza platform
VezaApplicationUrl: paste in the URL of the Veza instance copied above
VezaDiscoveryAccountId: this is the AWS account used by Veza to assume the read-only IAM role and discover resources in the target account. Leave the default value unless otherwise instructed.
VezaExternalId: this is the externalId that Veza will provide when attempting to assume the IAM Role in the target accounts. Set it to any UUID value.
VezaRDSUser: this is an existing local user account with read privileges that will be used to discover RDS resources.
In Step 3: Configure StackSet options, add any desired tags, ensure Managed execution is set to Inactive, and click Next
In Step 4: Set Deployment Options, provide the following, leaving the remaining options with their default values:
Deployment Targets: select either Deploy to organization or Deploy to organizational units (OUs).
If Deploy to organizational units is selected, provide up to 10 AWS OU IDs and an optional Account Filter Type
Specify Regions: select a single region into which the AWS Lambda function will be deployed for the target accounts. Warning: Ensure only one region is specifed for the deployment; selecting multiple regions will lead to conflicts and require manual intervention to remove.
In Step 5: Review, review the entered parameters, scroll to the bottom of the form, and accept the IAM Role disclaimer, then click Submit After the CloudFormation StackSet is provisioned, the integration is enabled. The Stack resources will be deployed into the target accounts and will register with the Veza platform as they complete.
Veza CloudFormation scripts are hosted on AWS S3. You can either use the defaults provided below or host your own modified versions. If using a customized template, you should update the Amazon S3 URL when creating the CloudFormation StackSet with the URL of your customized version.
CloudFormation Template Link: https://veza-controltower.s3.amazonaws.com/veza-aws-org-member-account.yaml
Discovering granular MySQL permissions with Veza
When connecting an AWS account to Veza, the recommended IAM policy includes permissions to discover RDS instances and clusters. To gather additional metadata, Veza will need to be able to execute database commands as a local user, as described in this document.
RDS MySQL databases are discovered by Veza via role assumption to a local MySQL user, granted the necessary read-only permissions. Veza creates authorization entities for:
RDS MySQL Database
RDS MySQL Function
RDS MySQL Instance
RDS MySQL Local User
RDS MySQL Local User Instance
RDS MySQL Procedure
RDS MySQL Role
RDS MySQL Role Instance
RDS MySQL Service
RDS MySQL Table
RDS MySQL Trigger
By default, extraction excludes the buil-in MySQL tables sys, performance_schema, information_schema, and mysql. These system-created tables are potentially of interest as they can contain sensitive data, and are discoverable on an optional basis. Enable Gather System Tables in the parent AWS integration configuration to show these Table entities and permissions in Veza.
You will need admin access and privileges to create a local user, which will be used to connect at runtime
An Insight Point is recommended for RDS MySQL discovery.
The Insight Point egress IP needs to be permitted in the RDS security group inbound rules.
Using an Insight Point is recommended when connecting to production environments. For testing purposes, you can use the internal Insight Point, assuming that firewall rules allow communication with Veza.
The MySQL User employed by Veza for extraction uses theAWSAuthenticationPlugin authentication method. RDS MySQL instances must be IAM DB Authentication-enabled.
RDS MySQL databases managed by Amazon Aurora are automatically discovered when RDS extraction is enabled for a configured AWS account.
Connected instances are mapped to the top-level Aurora RDS cluster in Authorization Graph search.
Since all instances in an Aurora cluster are replicas of the same MySQL database, each has the same database-level properties.
1. Configure the IAM Policy
Ensure that the IAM policy configured during AWS setup includes the <db_user> name of the MySQL user, and is the same as the RDS MySQL DB User name specified in AWS integration configuration. Below is a minimal policy allowing the required actions for discovery.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RDS",
"Effect": "Allow",
"Action": [
"rds:DescribeDBInstances",
"rds:DescribeDBClusters"
],
"Resource": "*"
},
{
"Sid": "RdsDbConnect",
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": "arn:aws:rds-db:<region>:<account_id>:dbuser:<cluster-name>/<db_user>"
}
]
}To discover individual RDS instances across multiple regions, you will need to create additional Resource entries in the Veza IAM policy for each region, for example:
"Resource": "arn:aws:rds-db:us-east-1:123456789:dbuser:*/veza_user"
"Resource": "arn:aws:rds-db:us-west-1:123456789:dbuser:*/veza_user"
Alternatively, you can use wildcard operator (*) to match all regions, accounts, and databases:
"Resource": "arn:aws:rds-db:*:*:dbuser:*/veza_user"
2. Create the local user
Connect to your database, and execute the following command to create a Veza User and grant the needed privileges for discovery. Replace [veza_user] with the name of the actual database user specified in your policy:
CREATE USER [veza_user] IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT REFERENCES ON *.* TO [veza_user];
GRANT SELECT ON mysql.user TO [veza_user];
GRANT SELECT ON mysql.db TO [veza_user];
GRANT SELECT ON mysql.tables_priv TO [veza_user];
GRANT SELECT ON mysql.columns_priv TO [veza_user];
GRANT SELECT ON mysql.global_grants TO [veza_user];
GRANT SELECT ON mysql.procs_priv TO [veza_user];
GRANT SELECT ON mysql.proxies_priv TO [veza_user];
-- Only if MySQL version is up to 5.7
GRANT SELECT ON mysql.proc TO [veza_user];
-- Only if MySQL version is 8+
GRANT SELECT ON mysql.role_edges TO [veza_user];
GRANT SHOW_ROUTINE ON *.* TO [veza_user];
-- If including triggers
GRANT TRIGGER ON *.* TO [veza_user];The next time Veza connects to the configured AWS account, the RDS MySQL server will be registered and appear under "Discovered Data Sources" on the Integrations > All Data Sources tab.
Integrate new AWS accounts in an organization using Landing Zones.
AWS Control Tower allows organizations to easily deploy AWS accounts into an organization, ensure that those accounts adhere to existing security policies, and create a baseline set of standard resources in each account.
Veza integrates with AWS Control Tower to automatically register accounts added to an AWS Control Tower Landing Zone. When an AWS account is provisioned within the OU, the provided CloudFormation template will create the required IAM resources in the AWS account, and create a new Veza integration.
Veza’s AWS Control Tower integration is delivered as an AWS CloudFormation template that can be installed in an organization’s Control Tower root account. The integration consists of three main infrastructure components:
An AWS Lambda function that runs in the Control Tower root account
This Lambda function executes when accounts are created or updated in the Control Tower Landing Zone (either by Service Catalog or Account Factory)
The function interacts with Veza APIs to ensure that the child account is registered as a Cloud Provider in the organization’s Veza instance
An IAM Role and Policy for the Control Tower root account to enable the Lambda function to execute and to read account update events in CloudWatch
An IAM Role and Policy for the child account to allow Veza to assume an IAM Role with read-only access and discover the resources inside the account
The Veza-provided cloud formation script runs on account enrollment and account update. Any existing AWS accounts will need to be re-enrolled to trigger the script in the parent account and integrate the child accounts with Veza.
Before deploying the Veza AWS Control Tower integration, two pieces of data are required from the Veza instance.
Make note of the URL used to connect to the Veza (ex: https://example.cookiecloud.ai)
Generate an API key for use by the Control Tower root account
The following steps should be completed in the AWS Control Tower root account by an administrator IAM user:
Log into the AWS console, click Services, then search for and select CloudFormation.
In the left navigation bar, click Stacks.
In the right corner of the main pane, click Create Stack, then select With new resources (standard) from the dropdown menu.
In Step 1: Specify Template form, enter https://veza-controltower.s3.us-east-2.amazonaws.com/veza.yaml as the Amazon S3 URL.
In Step 2: Specify Stack Details, provide the following details:
Stack Name: enter a display name for the CloudFormation Stack.
VezaApiToken: paste in the API key generated for the Veza instance.
VezaApplicationUrl: paste in the URL of the Veza instance copied above.
VezaDiscoveryAccountId: leave the default value unless otherwise instructed.
VezaExternalId: this is the externalId that Veza will provide when attempting to assume the IAM Role in the child account. It can be set to any value.
VezaManagedAccountTemplateUrl: use the default value unless hosting the CloudFormation templates in a non-Veza S3 bucket.
VezaRDSUser: this is the user account that will be used to discover RDS resources.
For Step 3: Configure Stack Options form, accept the default values, and click Next.
In Step 4: Review, review the entered parameters, scroll to the bottom of the form and accept the IAM Role disclaimer, then click Create Stack.
Once the CloudFormation Stack is provisioned, the integration is enabled.
To see the integration in action, create an AWS account inside the Control Tower Landing Zone
Log into the AWS console, click Services, then search for and select Control Tower.
In the left navigation bar, click Account Factory.
In the right corner of the main pane, click Enroll Account.
Complete the Enroll Account form with the following details:
An email account for the root account user.
A display name for the account.
SSO details for the account user.
Select a parent Organizational Unit where the account will be provisioned.
Click Enroll Account.
The account creation and enrollment process can take up to 30 minutes. Once finished, the account will show Enrolled in the Control Tower Accounts view.
Once the account shows as Enrolled, it will also be automatically integrated with the Veza instance referenced in the CloudFormation setup.
Any currently-enrolled AWS accounts must be re-enrolled to trigger the script and integrate them with Veza. To remove an account from management so that it can be re-enrolled with Control Tower:
Open the AWS Service Catalog.
Open the Provisioned products list.
Choose the account to remove from AWS Control Tower management.
Choose Terminate from the Actions menu and confirm the decision.
When successful, the account status will change to Not Enrolled.
For more information see Unmanage an account in the AWS documentation.
Veza CloudFormation scripts are hosted on AWS S3. You can either use the defaults provided below or host your own modified versions.
If using a customized template, you should update the Amazon S3 URL when creating the CloudFormation stack, and set an appropriate VezaManagedAccountTemplateUrl when specifying the stack details.
Environment
Root account YAML URL
Managed Account YAML URL
Production
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 a 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 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 analyzes cross-service connections between discovered entities, calculates effective permissions, and identifies authorization paths, including the cumulative effects of permission boundaries, service control policies, group memberships, and hierarchical policy statements. These relationships can be searched in the Authorization Graph, or audited using Workflows or the Query Builder.
To show external identities with access to AWS resources, Veza supports identity federation, displaying permissions for external users and groups from providers such as Okta, Azure AD, and custom identity providers.
Note that by default, all regions and services are extracted. Allow/deny lists can contain string lists (including wildcards) of resources names to ignore.
Supported entities:
Cognito Service
Cognito Identity Pool
Supported entities:
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.
Supported entities:
ECR Service
ECR Private Registry
ECR Private Repository
ECR Public Registry
ECR Public Repository
Supported entities:
EKS Service
EKS Cluster
Supported entities:
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.
Supported entities:
Redshift Cluster
Redshift Database
Redshift Schema
Redshift Effective Permission
Redshift Local User
Redshift Database Instance
Redshift Group
Redshift Table
Redshift Service
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:GetClusterCredentialsIAM privilege must be available.
Supported entities:
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. Access Points are not yet supported. 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.
Supported entities:
DynamoDB Service
DynamoDB Table
DynamoDB Secondary Index
DynamoDB Stream
See DynamoDB for more information.
Identity and Access Management
Supported entities:
AWS Accounts
IAM Groups
IAM Users
IAM Roles
IAM Policies
IAM Permissions
AWS IAM Policy entities have the attribute Permissions Boundary Usage Count, enabling queries on unused policies with no relationship to any principals.
Supported entities:
Identity Center Service
Identity Center User
Identity Center Group
Identity Center Permission Set
Identity Center is a service only available in the management account of an organization. To discover Identity Center entities, the region configured for the AWS account integration must match the region IAM Identity Center is enabled in. For example, if the IAM Identity Center is enabled in
us-east-1, the AWS Integration must have theus-east-1region defined. Otherwise, AWS IAM Identity Center will not appear as a Data Source.
Supported entities:
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.
Supported entities:
Lambda Service
Lambda Function
Supported entities:
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.
Supported entities:
RDS Service
RDS Instance
RDS Cluster
RDS Cluster Instance
RDS MySQL
Supported entities:
RDS MySQL Database
RDS MySQL Function
RDS MySQL Instance
RDS MySQL Local User
RDS MySQL Local User Instance
RDS MySQL Procedure
RDS MySQL Role
RDS MySQL Role Instance
RDS MySQL Service
RDS MySQL Table
RDS MySQL Trigger
RDS PostgreSQL
Supported entities:
PostgreSQL User
PostgreSQL Database
PostgreSQL Group
PostgreSQL Instance
PostgreSQL Schema
PostgreSQL Table
PostgreSQL Procedure
PostgreSQL Trigger
PostgreSQL Permissions
To get database-level metadata, users, and privileges, Veza will need to execute database queries as a local Postgres or MySQL user.
Supported entities:
Secrets Manager Service
Secrets Manager Secret
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.
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.
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.
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.
Configuring AWS Redshift for Veza discovery
The recommended AWS connector 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:GetClusterCredentialsIAM privilege is required. You can allow this via IAM policy in one of two ways, described in the steps below.
Additionally, the local user will also need read-only database permissions on the warehouses to discover.
A) AWS can automatically create a local user with the same name as the IAM principal initiating the connection. This can be accomplished in your policy using the condition key ${redshift:DbUser}, as in line 6 of the following example:
{
"Sid": "RedshiftCredentials",
"Effect": "Allow",
"Action": "redshift:GetClusterCredentials",
"Resource": [
"arn:aws:redshift:<region>:<account_id>:dbuser:<cluster-name>/${redshift:DbUser}",
"arn:aws:redshift:<region>:<account-id>:dbname:<cluster-name>/*"
]
},
{
"Sid": "RedshiftDescribe",
"Effect": "Allow",
"Action": [
"redshift:DescribeClusters",
"redshift-data:GetStatementResult",
"redshift-data:DescribeStatement"
],
"Resource": "*"
},
{
"Sid": "RedshiftExecute",
"Effect": "Allow",
"Action": "redshift-data:ExecuteStatement",
"Resource": "arn:aws:redshift:<region>:<account-id>:cluster:<cluster-name>"
}Note that the name of the provisioned Redshift user will be transformed to lowercase, and any dashes will be replaced with underscores (For an IAM user or role Veza-AI, the Redshift user name will be veza_ai).
You will still need to manually grant the SELECT privileges for the local user using the commands in the Grant Database Permissions section.
B) If you would prefer to connect as a local user that you will create yourself, you must specify that user explicitly in the policy, for example:
{
"Sid": "RedshiftCredentials",
"Effect": "Allow",
"Action": "redshift:GetClusterCredentials",
"Resource": [
"arn:aws:redshift:<region>:<account_id>:dbuser:<cluster-name>/<db_user>",
"arn:aws:redshift:<region>:<account-id>:dbname:<cluster-name>/*"
]
},
{
"Sid": "RedshiftDescribe",
"Effect": "Allow",
"Action": [
"redshift:DescribeClusters",
"redshift-data:GetStatementResult",
"redshift-data:DescribeStatement"
],
"Resource": "*"
},
{
"Sid": "RedshiftExecute",
"Effect": "Allow",
"Action": "redshift-data:ExecuteStatement",
"Resource": "arn:aws:redshift:<region>:<account-id>:cluster:<cluster-name>"
}Connect to the Redshift warehouse and create the user:
CREATE USER [veza_user] WITH PASSWORD 'YOUR_PASSWORD';The redshift-data:ExecuteStatement only allows the Veza service principal to run Redshift queries—the exact data Veza can access is governed within Redshift. Database permissions must be granted to the local user for each instance you want to discover.
Connect to the data warehouse and use the following GRANT SELECT command:
GRANT SELECT ON
pg_catalog.pg_user,
pg_catalog.pg_group,
pg_catalog.pg_database,
pg_catalog.pg_namespace,
pg_catalog.pg_class,
pg_catalog.pg_class_info,
pg_catalog.pg_attribute_info
TO
[veza_user];The next time Veza conducts discovery for the parent AWS account, the instance will be registered and appear under "Discovered Data Sources" on the Integrations > All Data Sources_ tab.
Early Access Using AWS Secrets Manager to store database extraction credentials is currently supported in Early Access for compatible integrations. Please contact our support team to enable this feature.
If your organization uses AWS Secrets Manager to manage and store RDS database credentials, you can configure an AWS account integration to use these secrets for RDS extraction, instead of storing the actual values in Veza.
This enables secure storage and key rotation in Secrets Manager, while granting the Veza service principal (an IAM user or role) access to those keys.
Secrets can use the AWS-provided "RDS secret" type, or be generic secrets, as long as they contain a value for the "username" and "password" keys. These values are used to log in as the local database user, configured with minimum permissions to extract database-level entities and authorization metadata.
To enable an integration to communicate with these RDS instances, you must configure a mapping of AWS secrets to instances with the following schema:
{
"resource_id": "<rds_instance_arn>",
"secret_id": "<secret_arn>"
}Additionally, AWS IAM policies must allow the Veza integration to read and decrypt the specified secrets.
This document describes the required IAM policies and API calls to enable this mapping for an AWS account in Veza.
For each AWS account that contains RDS instances, update the integration IAM policy to allow the Veza user or role to get the secrets associated with those resources.
For multi-account organizations where secrets are stored in another AWS account, you must also apply a resource policy on the secret and on the KMS key within that account, allowing the RDS account access to the secret.
Apply the following policies depending on your environment:
If the secret and RDS instance are located in the same AWS account, update the IAM policy for the integration to allow the Veza user or role to read (and decrypt, if required) the secret:
secretsmanager:GetSecretValue on the secret (always required)
kms:Decrypt on the CMK used to encrypt the secret, if a CMK was used instead of the AWS-managed key
The policy attached to the integration IAM user or role grants permissions to get the secret value from Secrets Manager and to decrypt the secret if it is encrypted with a KMS key:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"kms:Decrypt"
],
"Resource": [
"arn:aws:secretsmanager:your-region:<account-id>:secret:<your-secret-name>",
"arn:aws:kms:your-region:<account-id>:key/<your-key-id>"
]
}
]
}When the secret and RDS instances are in different accounts, you need to apply policies in both accounts:
Account A (where the secret is stored): Apply a resource policy on the secret in Secrets Manager and on the KMS key to allow the external account (Account B) to access the secret.
Account B (where the RDS instance resides): Apply an IAM policy to the role or user used to access the secret in Account A).
Account A: Secrets Manager Resource Policy
This resource policy allows the role from Account B to access the secret.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:region:account-A-id:secret:secret-id",
"Principal": {
"AWS": "arn:aws:iam::account-B-id:role/role-name"
}
}
]
}Account A: KMS Key Policy
This key policy allows the external role from Account B to decrypt the secret.
{
"Version": "2012-10-17",
"Id": "EnableCrossAccountAccess",
"Statement": [
{
"Sid": "AllowCrossAccountDecrypt",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::account-B-id:role/role-name"
},
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:region:account-A-id:key/key-id"
}
]
}Account B: IAM Policy for Integration Role or User
Add this statement to the integration IAM policy in the account containing the RDS instances. This will allow Veza to get and decrypt secrets in Account A.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"kms:Decrypt"
],
"Resource": [
"arn:aws:secretsmanager:region:account-A-id:secret:secret-id",
"arn:aws:kms:region:account-A-id:key/key-id"
]
}
]
}You can use an administrator API key to enable mappings for an AWS integration. Note that private APIs are subject to change as capabilities are added or modified.
GET
/private/providers/{provider_id}/secrets
PUT
/private/providers/{provider_id}/secrets
DELETE
/private/providers/{provider_id}/secrets
DELETE
/private/providers/{provider_id}/secret/{resource_id}
GET
/private/providers/{provider_id}/secret/{resource_id}
PUT
/private/providers/{provider_id}/secret/{resource_id}
When making API requests, ensure that the resource_id parameter is URL-encoded. This is particularly important because the resource_id can be an AWS ARN or an SQL connection string. These values can contain special characters, such as : and /, which can interfere with API routing if not properly encoded.
For example, if the resource_id is arn:aws:rds:us-west-2:123456789012:db:mysql-db, the URL-encoded request should be:
GET <BASE URL>/private/providers/123/secrets/arn%3Aaws%3Ards%3Aus-west-2%3A123456789012%3Adb%3Amysql-dbList all resource-to-secret mappings for an AWS Integration
GET <BASE URL>/private/providers/{provider_id}/secrets
Response:
{
"secrets": [
{
"resource_id": "<rds_instance_arn1>",
"secret_id": "<secret_arn1>"
},
{
"resource_id": "<rds_instance_arn2>",
"secret_id": "<secret_arn2>"
}
]
}Set a mapping of all secrets for an AWS integration.
PUT <BASE URL>/private/providers/{provider_id}/secrets
Request body:
{
"secrets": [
{
"resource_id": "<rds_instance_arn1>",
"secret_id": "<secret_arn1>"
},
{
"resource_id": "<rds_instance_arn2>",
"secret_id": "<secret_arn2>"
}
]
}Delete all secrets mapped for an integration, specified by AWS integration ID.
DELETE <BASE URL>/private/providers/{provider_id}/secrets
Remove a single mapping, specified by ID.
DELETE <BASE URL>/private/providers/{provider_id}/secret/{resource_id}
Return the secret id for a specified resource.
GET <BASE URL>/private/providers/{provider_id}/secret/{resource_id}
Request body:
{
"secret_id": "<secret_arn>"
}Update the integration secrets mapping to use a new secret ID for the specified resource.
PUT <BASE URL>/private/providers/{provider_id}/secret/{resource_id}
Request body:
{
"secret_id": "<secret_arn>"
}