turbot / steampipe-mod-aws-perimeter

Is your AWS perimeter secure? Use Powerpipe and Steampipe to check your AWS accounts for public resources, resources shared with untrusted accounts, insecure network configurations and more.

AWS Perimeter Mod for Powerpipe

Important

Powerpipe is now the preferred way to run this mod! Migrating from Steampipe →

All v0.x versions of this mod will work in both Steampipe and Powerpipe, but v1.0.0 onwards will be in Powerpipe format only.

An AWS perimeter checking tool that can be used to look for resources that are publicly accessible, shared with untrusted accounts, have insecure network configurations, and more.

Run checks in a dashboard:

Or in a terminal:

Documentation

• Benchmarks and controls →
• Named queries →

Getting Started

Installation

Install Powerpipe (https://powerpipe.io/downloads), or use Brew:

brew install turbot/tap/powerpipe

This mod also requires Steampipe with the AWS plugin as the data source. Install Steampipe (https://steampipe.io/downloads), or use Brew:

brew install turbot/tap/steampipe
steampipe plugin install aws

Steampipe will automatically use your default AWS credentials. Optionally, you can setup multiple accounts or customize AWS credentials.

Finally, install the mod:

mkdir dashboards
cd dashboards
powerpipe mod init
powerpipe mod install github.com/turbot/steampipe-mod-aws-perimeter

Browsing Dashboards

Start Steampipe as the data source:

steampipe service start

Start the dashboard server:

powerpipe server

Browse and view your dashboards at http://localhost:9033.

Running Checks in Your Terminal

Instead of running benchmarks in a dashboard, you can also run them within your terminal with the powerpipe benchmark command:

List available benchmarks:

powerpipe benchmark list

Run a benchmark:

powerpipe benchmark run public_access

Run a specific control:

powerpipe control run ec2_instance_ami_prohibit_public_access

Different output formats are also available, for more information please see Output Formats.

Configure Variables

Several benchmarks have input variables that can be configured to better match your environment and requirements. Each variable has a default defined in its source file, e.g., perimeter/shared_access.sp, but these can be overwritten in several ways:

It's easiest to setup your vars file, starting with the sample:

cp steampipe.spvars.example steampipe.spvars
vi steampipe.spvars

Alternatively you can pass variables on the command line:

powerpipe benchmark run shared_access --var='trusted_accounts=["123456789012", "123123123123"]'

Or through environment variables:

export PP_VAR_trusted_accounts='["123456789012", "123123123123"]'
powerpipe control run ram_resource_shared_with_trusted_accounts

These are only some of the ways you can set variables. For a full list, please see Passing Input Variables.

Common and Tag Dimensions

The benchmark queries use common properties (like account_id, connection_name and region) and tags that are defined in the form of a default list of strings in the variables.sp file. These properties can be overwritten in several ways:

It's easiest to setup your vars file, starting with the sample:

cp steampipe.spvars.example steampipe.spvars
vi steampipe.spvars

Alternatively you can pass variables on the command line:

powerpipe benchmark run public_access_settings --var 'common_dimensions=["account_id", "connection_name", "region"]'

Or through environment variables:

export PP_VAR_common_dimensions='["account_id", "connection_name", "region"]'
powerpipe control run eks_cluster_endpoint_prohibit_public_access

Open Source & Contributing

This repository is published under the Apache 2.0 license. Please see our code of conduct. We look forward to collaborating with you!

Steampipe and Powerpipe are products produced from this open source software, exclusively by Turbot HQ, Inc. They are distributed under our commercial terms. Others are allowed to make their own distribution of the software, but cannot use any of the Turbot trademarks, cloud services, etc. You can learn more in our Open Source FAQ.

Get Involved

Join #powerpipe on Slack →

Want to help but don't know where to start? Pick up one of the help wanted issues:

• Powerpipe
• AWS Perimeter Mod

steampipe-mod-aws-perimeter's Issues

Update mod.sp to address deprecation warning

Describe the bug
The current version of the mod returns a warning due to using the deprecated option version instead of min_version for the aws plugin.

This issue can be trivially resolved by updating

  require {
    plugin "aws" {
      version = "0.70.0"
    }
  }

to

  require {
    plugin "aws" {
      min_version = "0.70.0"
    }
  }

Steampipe version (steampipe -v)
Example: v0.3.0

Plugin version (steampipe plugin list)
Example: v0.5.0

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Add additional dimensions to queries

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Control elb_application_lb_waf_enabled providing incorrect result

Describe the bug
Perimeter Mod is flagging it as disabled even though WAF is enabled for an ELB.

Slack reference - https://steampipe.slack.com/archives/C01UECB59A7/p1657569823027209

Steampipe version (steampipe -v)
Example: v0.15.0

Plugin version (steampipe plugin list)
Example: v0.68.0

To reproduce
steampipe check aws_perimeter.control.elb_application_lb_waf_enabled

Expected behavior
It should return the correct result.

Additional context
Add any other context about the problem here.

Add trusted controls for AWS policies

Is your feature request related to a problem? Please describe.
Improve the mod by adding controls which check if resource policies are shared with trusted entities and if not, alert the report generator of the issue.

Describe the solution you'd like
The solution should look similar to that of the IAM public access controls.

Describe alternatives you've considered
Planned work

Additional context
None needed

Update resource policy public access controls to evaluate common conditions

Is your feature request related to a problem? Please describe.
When running controls, conditions are not currently evaluated, so if I have a statement like:

{
    "Principal": "*", 
    "Resource": "*", 
    "Action": "s3:PutObject", 
    "Effect": "Allow", 
    "Condition": { "StringLike": {"aws:SourceAccount": "123456789012"}}
}

The control should not alarm, but instead return ok.

Describe the solution you'd like
The controls should check for common conditions like SourceArn, SourceAccount, and SourceOwner.

Describe alternatives you've considered
Checking any false positives

Additional context
Add any other context or screenshots about the feature request here.

Error when defined trusted accounts parameter

Describe the bug
When I configure the parameter

# List of trusted accounts
trusted_accounts = ["123456789012", "210987654321"]

The control EC2 AMIs should only be shared with trusted accounts fails with the error message.

failed to encode args[0]: unable to encode []string{"123456789012", "210987654321"} into text format for text (OID 25): cannot find encode plan

Steampipe version (steampipe -v)
0.20.8

Plugin version (steampipe plugin list)
hub.steampipe.io/plugins/turbot/aws@latest - 0.108.0 - aws
hub.steampipe.io/plugins/turbot/steampipe@latest - 0.8.0 - steampipe

To reproduce
Ensure the spvars file uses a trusted_accounts value

Expected behavior
Should behave the same way as other controls that use the parameter.

Additional context
None

Add initial mod file and structure

aws_perimeter.control.s3_bucket_policy_prohibit_public_access check reports OK for buckets it can't process

Running the AWS perimeter mod control aws_perimeter.control.s3_bucket_policy_prohibit_public_access fails with the error

Error: operation error S3: GetBucketLocation, https response error StatusCode: 403, RequestID: <REDACTED>, HostID: <REDACTED>, api error AccessDenied: Access Denied (SQLSTATE HV000)

This looks to be down to several buckets with messed up permission policies.
So I modified the steampipe configuration to include

ignore_error_codes = ["AccessDenied", "AccessDeniedException", "NotAuthorized", "UnauthorizedOperation", "UnrecognizedClientException", "AuthorizationError"]

This at least allows the control to run to a conclusion however, the buckets that previously caused the control to fail now report OK

OK : <BUCKET NAME REDACTED> policy does not allow public access. .......................................................... <nil> <ACCOUNT NAME REDACTED>

Steampipe version (steampipe -v)
v0.17.4

Plugin version (steampipe plugin list)

+--------------------------------------------------+---------+-------------+
| Installed Plugin                                 | Version | Connections |
+--------------------------------------------------+---------+-------------+
| hub.steampipe.io/plugins/turbot/aws@latest       | 0.91.0  | aws         |
| hub.steampipe.io/plugins/turbot/steampipe@latest | 0.6.0   | steampipe   |
+--------------------------------------------------+---------+-------------+

To reproduce
Create a bucket policy which only allows access to a specific role.

Expected behavior
Should these particular resources be flagged as ERROR, as the credentials being used are insufficient for these buckets to be evaluated even though certain error codes are being ignored?

KMS check does not take into account KMS specific conditionals

Running the AWS perimeter mod control aws_perimeter.control.kms_key_policy_prohibit_public_access reports alerts against an AWS generated KMS policy. AWS documentation calls out the default kms policy created for CloudTrail trails. AWS creates a condition based policy that leverages a condition that uses kms:CallerAccount. The perimeter mod check only takes into account aws:SourceOwner, aws:SourceAccount, aws:PrincipalOrgID, aws:PrincipalAccount, aws:PrincipalArn and aws:SourceArn.

Should kms:CallerAccount not be a candidate for the where clause when analysing KMS resources?

Update Resource Policy Public Access controls to align with additional services supported by AWS

A significant number of AWS Services, in addition to those currently supported by the mod, support resource-based policies.

Could the current list of controls be enhanced to consider services referenced within the AWS documentation? Link https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

This link has a dedicated column for resource-based policy support and identifies which services are supported.

Add initial public access controls