Objective
The post will guide you on how to setup your AWS environment to be ready to work with the SkyFormation for AWS MT cloud connector.
In order to monitor CloudTrail from multiple AWS accounts, AWS instructs the user to forward the trails from the various accounts into a single account’s S3 Bucket, and to also setup a SQS queue that is notified when new objects are added to that bucket.
See AWS’s guides [1] [2] for what we’re attempting to acheive.
In this guide we will implement this architecture within AWS, including the creation of the collecting bucket, the sqs queue, the various accounts’ trails, all with air-tight permissions/policies,
and finally we will create an AWS IAM User with permissions to orchestrate this setup, again, with air-tight policy.
Preparation
Collect all the account numbers that will be sending CloudTrail events.
Account # can be found at My Account under Account Settings -> Account ID, as a 12 digit number, i.e. 111111111111
AWS Services Setup
In the account the will have the trails sent to it (e.g. Account A):
- Create an S3 bucket. Keep its ARN aside. A bucket’s ARN can be found at its properties tab.
- Create an SQS Queue (Both Standard and FIFO types are OK). Make sure the Queue is in the same region as the bucket. Keep its URL and ARN aside.
- Set a policy for the SQS Queue to only allow the S3 bucket to send events to it :
In SQS, select our queue -> Permissions, click “Edit Policy Document (Advanced)” and paste the following policy - modify accordingly:
{
"Version": "2012-10-17", "Id": "queue ARN/SQSDefaultPolicy", "Statement": [
{ "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": ["SQS:SendMessage"], "Resource": "queue ARN", "Condition": { "ArnLike": { "aws:SourceArn": "bucket ARN" } } } ] } - Configure the S3 Bucket to notify the SQS Queue when files are added to it :
In S3, select our bucket -> Properties (Tab) -> Events -> “+ Add notification”, set a meaningful name (i.e. “Notify SQS new Files”), check “ObjectCreate (All)”, under “Send to” select “SQS Queue”, Select our queue and save. - Set a policy for the S3 Bucket to only allow the accounts that are destined to send CloudTrail events to this bucket to add objects to it :
In S3, select our bucket -> Permissions -> Bucket Policy and paste the following policy - modify accordingly; add a row with the account ID for each source account:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "Bucket ARN" }, { "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:PutObject", "Resource": [ "Bucket ARN/[optional] myLogFilePrefix/AWSLogs/Account ID 1/*", "Bucket ARN/[optional] myLogFilePrefix/AWSLogs/Account ID 2/*" ], "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } } ] }
-
Configure a CloudTrail for each account to send its events to our bucket in Account A:
-
- Login to desired account
- In CloudTrail, create a new trail (or re-configure an existing one)
- Under “Storage location” check “No” in “Create new bucket” and set the bucket name (not ARN) of Account A
-
-
Choose your preferred Authentication method:
AWS Cloud Connector Authentication Options
Exabeam Cloud Connectors offer 3 methods for cloud connectors module authentication with AWS:
- InstanceProfile:
This is the recommended authentication method if the instance where cloud connector is running is in AWS EC2, and the AWS account we want to collect data from is the same as the one where the machine is hosted.
To use this method, you will need to create and IAM policy and assign it to a role, then assign the role with the required permissions to the EC2 instance running the SkyFormation app.
For further reading, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html. - STSAssumeRole:
This is the recommended method for authentication by AWS. It also allows for cross-account access.
The credentials for the IAM user (i.e. "Basic") are used to authenticate with the user that will then assume the role. That user does not need any other permission other than the ability to assume the role specified.
For further reading: https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html.
- Basic :
Via the access key and secret of an IAM User.
For any of the above methods, an IAM Policy is needed.
- InstanceProfile:
-
Create IAM Policy (required):
In your AWS console, navigate to Services --> IAM --> Policies --> Create policy. Click on the "JSON" tab, to get an online editor. Replace the default, empty Json with the JSON in below (Modify as appropriate):
Name the policy accordingly, e.g. “SQS and S3 for Exabeam Cloud Connectors”.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "sqs:DeleteMessage", "sqs:DeleteMessageBatch", "sqs:ReceiveMessage" ], "Effect": "Allow", "Resource": "Queue ARN" }, { "Action": [ "s3:GetObject" ], "Effect": "Allow", "Resource": "Bucket ARN/*" } ] }
-
Create User - required only for Basic and AssumeRole Authentication:
Create a user with the policy from step 5:
In Account A:- In your AWS console, navigate to Services --> IAM --> Users --> Add user.
- Give your user a name and check the programmatic access checkbox:
- When you click next, you will be transferred to the set permissions page.
- For Basic Authentication only, Choose "Attach Existing Policies Directly", and search for the policy you created in the previous step. (For STSAssumeRole authentication skip this step, you will be warned about user has no permissions - this is OK).
- Continue the user creation process (tags are optional) and finish the user creation. You will see a screen like the following :
You need the following attributes in the next step:
- Secret Access Key (e.g. see in the diagram an example)
- Access Key ID (e.g. see in the diagram an example)
Note: The Access Key ID and Secret Access Key in the diagram are not valid keys.
-
Create an IAM Role - Required for AssumeRole and InstanceProfile authentication:
-
-
- Navigate to IAM -> Roles. Click "Create Role"
- Select AWS Service box, and EC2 service and Click "Next: Permissions"
- This will create a "Trust relationship" that'll allow Allows EC2 instances to call AWS services on your behalf. We will modify the Trust relationship document later, per authentication method you'll choose
- Search the policy created earlier and check its checkbox. Click "Next: Tags"
- Optionally add tags. Click "Next: Review"
- Give it a meaningful name, e.g. ExabeamCCAWSConnectorRole, and description. Click "Create Role".
- Search for the created role and click on it. Copy aside the role's ARN.
-
-
- Finalize AssumeRole and InstanceProfile authentication configuration:
AssumeRole:
- Navigate to IAM -> Roles and search for the role created earlier
- Allow a specific user to use (assume) the role
- Go to "Trust relationships" tab, click "Edit trust relationship"
- Make sure the "Statements" array contains the following entry (modify accordingly):
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/ccuser"
},
"Action": "sts:AssumeRole"
} - Click "Update Trust Policy"
InstanceProfile:-
-
-
- Navigate to IAM -> Roles and search for the role created earlier
- Allow EC2 instances to use (assume) the role
- Go to "Trust relationships" tab, click "Edit trust relationship"
- Make sure the "Statements" array contains the following statement entry:
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
} - Click "Update Trust Policy"
- Navigate to AWS EC2 service
- Right-click on the instance where Cloud Connectors in installed, Click Instance Settings -> Attach/Replace IAM Role
- Choose the role from the drop-down list, and Apply
Done!
-
-
Whats Next
You can now proceed with on-boarding a MultiTenant AWS connector in SkyFormation
Comments
0 comments
Please sign in to leave a comment.