AWS LPA Setup
Deploying and configuring the AWS LPA feature for InsightCloudSec
Prior to getting started with the Principal Activity capability, users will be required to complete configuration to enable the system to properly import and display the associated data. Note: These settings are displayed as "LPA Configuration" within InsightCloudSec as the Principal Activity capability is the first component of our future LPA feature.
These requirements consist of the following:
- Creating/Validating the appropriate IAM Roles and Permissions
- Creating CloudTrails (this step is optional if you have an existing CloudTrail you plan to use with Principal Activity/LPA)
- Updating Data Settings & Configuration within InsightCloudSec
If you have any questions or issues with Principal Activity reach out through any of the options outlined on the Getting Support page.
IAM Roles and Permissions
Permissions
Principal Activity (LPA) requires multiple services and different roles to work correctly. The permissions from the following AWS services are required:
- Athena: Main Query Executor
- Glue: Used for retrieving the schema information
- S3: CloudTrail source inputs, and Working bucket outputs
Policy
New Onboarding
As of InsightCloudSec v. 23.4.11, the new onboarding experience for AWS accounts uses CloudFormation Templates (CFTs) to automatically provision relevant accounts with the necessary policies and roles. This means it is easiest to perform LPA configuration while onboarding an account/organization. Review AWS Cloud - Onboarding for more information.
The Egress LPA Auto Provisioning Policy grants the Rapid7 IAM Role permission to access CloudTrail, to create the necessary AWS Glue tables, and to create/execute Athena queries with a S3 bucket for results.
- Note: This links to a generic policy and there are fields you will need to update to reflect your specific environment.
Creating a CloudTrail
Before getting started with Principal Activity you will need to have CloudTrail configured to enable Principal Activity (LPA). Most users typically have a CloudTrail configured; in this instance, skip to the setup within InsightCloudSec and use your existing CloudTrail setup information.
New CloudTrail
If you do not already have a CloudTrail configured or would rather create a new, separate CloudTrail, refer to the AWS documentation on how to create a new CloudTrail and note the following recommendations:
- Create a new S3 bucket to go with the CloudTrail
- Enable log file SSE-KMS encryption (with a new KMS key)
- Choose to log Management events (both Read and Write)
- Choose to log Data events and Insights events, but note that this will incur additional CloudTrail costs
Attaching Policy to CloudTrail Bucket
If possible, you should grant bucket access to the harvesting IAM Role within the same AWS Account as the CloudTrail bucket. This way you only need to grant permissions in one place and any security checks about cross account bucket won’t be raised. To add a policy to the new CloudTrail bucket:
1. Navigate to the the S3 service in the AWS Console for the same account you created the CloudTrail.
2. Find the new CloudTrail bucket you just created in the previous section and click its name to open it.
3. Click the "Permissions" tab.
4. In the Bucket policy section, click "Edit".
5. Append the following statement to the bucket policy, ensuring you replace the placeholder values:
{
"Sid": "AllowS3ObjectAccessToRapid7EgressRole",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Principal": {"AWS": "arn:{partition}:iam::{account_id}:role{role_name}"},
"Resource": ["arn:{partition}:s3:::{target_bucket}", "arn:aws:s3:::{target_bucket}/*"]
}
6. Click "Save Changes".
Troubleshooting
Scenario: What if the S3 bucket is encrypted with a KMS key?
If the S3 objects are being encrypted with a custom KMS key, then the KMS resource policy must grant kms:Decrypt permissions to the IAM Role. Append the following policy statement (ensuring you replace the placeholder values) to the KMS policy to explicitly grant access to use this KMS key for only the CloudTrail bucket:
{
"Sid": "AllowS3ObjectAccessToRapid7EgressRole",
"Effect": "Allow",
"Action": ["kms:Decrypt"],
"Principal": {"AWS": "arn:{partition}:iam::{account_id}:role{role_name}"},
"Resource": ["arn:{partition}:s3:::{target_bucket}", "arn:aws:s3:::{target_bucket}/*"]
}
Scenario: What if Cross Account access is required?
Some strategies for AWS Organization setup require access to CloudTrail logs to come from another Account. In this scenario, you must grant bucket access permissions to the IAM Role using a custom IAM Managed Policy in addition to the S3 bucket policy (ensuring you replace the placeholder values). Likewise, if the bucket is encrypted, the kms:Decrypt permission needs to be included as well.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ObjectAccess",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:{partition}:s3:::{target_bucket}", "arn:aws:s3:::{target_bucket}/*"]
},
{
"Sid": "AllowKMSDecryptAccess",
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:{partition}:kms:{region_name}:{account_id}:key/{key_id}"
}
]
}
Scenario: What if my InsightCloudSec harvesting role denies the "s3:GetObject\*" permission (e.g., you're using the AWS Managed Read Only Supplemental Role)?
You can still maintain the deny permission but you'll need to provide explicit access to the CloudTrail buckets by using NotResource, which has the effect of denying s3:GetObject* for all buckets except the ones you specify. See the example below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AwsReadOnlyMissingPermissions",
"Action": [
"airflow:GetEnvironment",
"aoss:BatchGetCollection",
"aoss:GetSecurityPolicy",
"aoss:ListCollections",
"aoss:ListSecurityPolicies",
"apprunner:DescribeService",
"apprunner:ListServices",
"backup-gateway:GetGateway",
"docdb-elastic:GetCluster",
"docdb-elastic:ListClusters",
"eks:AccessKubernetesApi",
"lookoutequipment:DescribeDataset",
"lookoutequipment:ListDatasets",
"memorydb:DescribeClusters",
"memorydb:DescribeSubnetGroups",
"memorydb:ListTags",
"oam:GetSinkPolicy",
"oam:ListLinks",
"oam:ListSinks",
"pricing:GetProducts",
"quicksight:DescribeAccountSettings",
"quicksight:DescribeAccountSubscription",
"quicksight:DescribeIpRestriction",
"quicksight:ListUsers",
"redshift-serverless:ListNamespaces",
"redshift-serverless:ListWorkgroups",
"support:*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "AwsReadOnlyDenyPermissions",
"Action": [
"dynamodb:BatchGetItem",
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query"
],
"Effect": "Deny",
"Resource": "*"
},
{
"Sid": "FixLPAAwsReadOnlyDenyPermissions",
"Action": [
"s3:GetObject*"
],
"Effect": "Deny",
"NotResource": [
"arn:aws:s3:::insightcloudseclpa",
"arn:aws:s3:::insightcloudseclpa/*"
]
}
]
}
Settings & Configuration
These steps assume you have all of the appropriate configuration details on hand to complete the Principal Activity (LPA) configuration within InsightCloudSec.
Notes on LPA CloudTrail Sources
InsightCloudSec supports multiple sources of CloudTrail data, if desired. Before you add a source, ensure you have:
- A unique name for identification purposes
- An S3 URI that points at the CloudTrail source. Note: This directory MUST POINT TO A DIRECTORY OF ACCOUNT IDS. Thus, the prefix specified, when viewed in the S3 management console, must show a list of directories representing account IDs.
- Credentials with
s3:GetObjectands3:ListBucketaccess to the CloudTrail S3 URI, write access to the LPA S3 working bucket, and Athena query read/execute permissions.Note: Our LPA system does not filter CloudTrail events, so please configure the CloudTrail source appropriately to log all of the events (read and/or write) that you want to see inside of the InsightCloudSec. We recommend that both read and write management events be enabled for the CloudTrail source; otherwise, the full list of used permissions will not be displayed in the LPA analysis.
Authentication Role
If Authentication Type Assume role is selected, a trust needs to be allowed for the harvest role you created, not the InsightCloudSec install role.
1. Select the gear icon at the top right of InsightCloudSec (next to your profile), then navigate to "IAM Settings --> AWS LPA Working Directory".
LPA Configuration - AWS LPA Working Directory
2. Complete the form/fields as follows:
Working Directory Location
- S3 URI: Update with the S3 bucket details associated with the bucket where your LPA (Principal Activity) will be stored. We recommend that:
- You create an S3 bucket that is dedicated to storage of the LPA (Principal Activity) data
- This dedicated bucket resides in the same location as your InsightCloudSec installation
Working Directory Authentication
- Authentication Type: Select the credentials associated with the bucket you have configured to store LPA (Principal Activity) data
- The fields will vary based on the credential type (e.g., Use Cloud Credentials, Assume Role, or STS Role)
- Note: The selected credentials must have read/write access to the specified S3 bucket URI.
Test Settings
This button allows you to confirm that you have supplied a valid configuration. If you receive an error the issues may be the result of an incorrect S3 URI, misconfigured policies, or invalid IAM credentials.
Success - Valid Test Settings
Deleting Settings
Once settings have been tested and validated, you can delete them at any point to prevent unwanted LPA costs. Just return to this page and click "Delete Settings".
LPA CloudTrail Sources
1. From the IAM Settings page, click "AWS LPA CloudTrail Sources" under the LPA Configuration options.
2. Click "Create Configuration".
3. Update with the S3 bucket details associated with the CloudTrail you want to use and click "OK".
New CloudTrail Configuration
Updated 6 months ago