Identify risks of excess AWS IAM permissions with the k9 CLI

Now you can quickly identify risks to your data and encryption resources with the k9 CLI. Sifting through the access capabilities in an AWS account with many resources and principals can be daunting, especially because some analysis rules vary by AWS account. So now you can identify resources that are overly-accessible and principals that are over-permissioned with k9 CLI’s two new subcommands using your own access limits. Use these new commands to determine if your IAM policies allow too much access to specific AWS service resources such as S3 buckets and KMS encryption keys.

Analyze excess permissions to specific AWS resources in terms of the simplified k9 Access capability model: administer-resource, read-config, read-data, write-data, delete-data.

First let’s see how to identify overly-accessible data resources, then over-permissioned principals

Identify overly-accessible data and encryption resources

Identify resources that can be accessed by more principals than you intend (Kata 5) with the k9 query risks over-accessible-resources command.

Suppose you want to find excess permissions to your S3 resources.

Which S3 buckets are too accessible?

Find the S3 buckets where more than 3 principals can read data with:

k9 query risks over-accessible-resources \
    --customer_id $K9_CUSTOMER_ID \
    --account $K9_ACCOUNT_ID \
    --analysis-date $ANALYSIS_DATE \
    --format json \
    --service S3 \
    --max-read 3 \
      | jq '.[].resource_arn'

This command produces a list of S3 buckets where more than 3 principals can read the data:

"arn:aws:s3:::k9-cdk-public-website-test"
"arn:aws:s3:::aws-cloudtrail-logs-139710491120-test2"
"arn:aws:s3:::k9-temp-audit-resources-dev-9c3a9e12"
"arn:aws:s3:::k9-testenv-testbucket-custom-policy-8511ead4"
"arn:aws:s3:::trusted-network-example"

Each resource’s object lists the principals for each capability so you can process the output further in your own scripts:

  {
    "service_name": "S3",
    "resource_name": "k9-cdk-public-website-test",
    "resource_arn": "arn:aws:s3:::k9-cdk-public-website-test",
    "principals_by_capability": {
      "read-data": [
        {
          "principal_arn": "arn:aws:iam::139710491120:user/ci",
          "principal_name": "ci",
          "principal_type": "IAMUser"
        },
      ],
      ... snip ...
    }
  ... snip ...

You can identify excessive access to any AWS service resource where k9 supports resource level analysis, currently: KMS, DynamoDB, RDS, S3, and STS.

After examining access to your most critical data and encryption resources, you might want to identify principals with too much access to data resources.

Identify principals with too much access to data and encryption resources

Identify principals with too much access to data and encryption resources (Kata 4) with the k9 query risks over-permissioned-principals command. This is especially handy for finding ‘shadow admin’ and other principals that can access to broad swaths of data resources.

So which principals have too much access to S3?

Find the principals who can administer more than 5 S3 buckets with:

k9 query risks over-permissioned-principals \
    --customer_id $K9_CUSTOMER_ID \
    --account $K9_ACCOUNT_ID \
    --analysis-date $ANALYSIS_DATE \
    --format json \
    --service S3 \
    --max-admin 5 \
      | jq '.[].principal_arn'

This command produces a list of principals with ability to administer more than 5 buckets:

"arn:aws:iam::139710491120:user/skuenzli"
"arn:aws:iam::139710491120:role/aws-service-role/support.amazonaws.com/AWSServiceRoleForSupport"
"arn:aws:iam::139710491120:user/ci"
"arn:aws:iam::139710491120:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_437be9d757c9ea2f"
"arn:aws:iam::139710491120:role/cdk-hnb659fds-cfn-exec-role-139710491120-us-east-1"

You can use this query to quickly find principals for applications, platform, and people that can read, write, or delete data they shouldn’t. You may want to start with high limits to discover the principals that have the most excessive access, i.e. read access to nearly all of the buckets in the account.

Automate your analysis with custom access limits

We want you to be able to analyze IAM access scalably, repeatably, and quickly. So we built the CLI so you can analyze excess permissions one k9 capability at a time and with custom ‘max’ limits for each account. Check out the new demo script in the k9 CLI GitHub repository for an example of how to sync your reports and query them for these and other risks like privilege escalation by IAM admins.

Full usage of the k9 CLI is documented in the README.

We’re happy to answer any questions, just drop an email to [email protected] or open an issue on GitHub.