AWS Service Configuration

Harvesting Cadences

Due to the global scope, count, and scale of S3 buckets, we recommend that the harvest cadence for Storage Containers be no less than 30 minutes.

Impaired Visibility

Customers using AWS will have improved visibility warnings if an S3 bucket’s properties are unable to be harvested due to an overly restrictive bucket policy.

While there are multiple policy possibilities that can prevent complete harvesting of an S3 bucket, here's an example policy that will show as impaired in InsightCloudSec:

json
1
{
2
    "Version": "2008-10-17",
3
    "Statement": [
4
        {
5
            "Sid": "DenyAll",
6
            "Effect": "Deny",
7
            "Principal": "*",
8
            "Action": [
9
                "s3:GetBucketLogging",
10
                "s3:GetBucketPolicy",
11
                "s3:GetEncryptionConfiguration"
12
            ],
13
            "Resource": "arn:aws:s3:::myimpairedbucket"
14
        }
15
    ]
16
} 

Because the bucket policy denies all principals, InsightCloudSec won't be able to harvest the bucket logging, policy, or encryption statuses.

Other Causes

In addition to the policy example above other possible causes include:

• inability to get the bucket location
• inability to get the bucket ACL
• inability to get IAM policy details
• inability to get versioning config
• inability to get static website config
• inability to get lifecycle policy config
• inability to get encryption settings

To get more information about what specific call(s) failed, you can run sudo docker-compose logs | grep "Unable to retrieve" | grep "yourbucketname" on the instance you have running InsightCloudSec.

Update the command with your unique bucket name.

For visibility and reporting, you can use the filter Storage Container With Impaired Visibility to alert you when there's a bucket policy in place that prevents visibility for InsightCloudSec.

Elastic Beanstalk

InsightCloudSec includes support and visibility for AWS Elastic Beanstalk that includes filter and enhanced insight into both Elastic Beanstalk Applications and Environments. To view details, go to Compute > WebAppGroup.

AWS Elastic Beanstalk can include many instances, ASGs, etc., linked to a given environment. The following resource types are supported by InsightCloudSec and can be linked to an environment:

• Instances
• Auto Scaling groups
• Launch configurations
• Load balancers
• Queues

For the newest and extensive set of AWS read permissions required, go to AWS Latest Elastic Beanstalk.

Automatic patching

InsightCloudSec includes a data point for WebApps: automatic_patching. It is exclusive to AWS Beanstalk and tracks whether or not Managed Actions are enabled. To support Beanstalk resources we added the following filters:

• Instance Managed By Web App
• Web App With Automatic Patching Enabled
• Web App With Automatic Patching Disabled

With Beanstalk you can have multiple runtime versions so we added a new column on the resources page to display this information.

Permissions

When Beanstalk make sure that you have given InsightCloudSec the proper permissions for all the supported resources (see list below) used by your Beanstalk app/environment.