AWS Access Policy Anonymous Access Controls

Overview

This guide describes how Turbot evaluates and manages anonymous access for various access policies, e.g., IAM trust role policies, S3 bucket policies, and SQS access policies, and how to configure Turbot policies to deny anonymous access.

Elements in a Policy

The basic elements in a policy are:

  • Sid: Unique identifier for each statement
  • Effect: Can be set to “Allow” or “Deny”
  • Principal: Principal entity that is allowed/denied access to the resource(s)
  • Action: IAM actions that are allowed/denied
  • Resource: Object(s) included in this statement
  • Condition: Specify conditions for when this statement is in effect

More information on all elements can be found in IAM JSON Policy Elements Reference.

Process of Evaluating Anonymous Access

The principal in each statement supports the following types:

  • AWS: AWS account ID, IAM user, or IAM role
  • Federated: Web identity source, e.g., graph.facebook.com, accounts.google.com, or SAML identity provider
  • Service: AWS service, e.g., cloudtrail.amazonaws.com, s3.amazonaws.com
  • Anonymous: Grant anonymous access with * or "AWS": "*"

Only "AWS": "*" and * principals are checked for anonymous access as the other types of principals are evaluated in their own set of guardrails.

The following S3 bucket policy allows anonymous access:

{
  "Sid": "Allow anonymous access",
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "s3:GetBucketLocation",
    "s3:ListBucket"
  ],
  "Resource": "arn:aws:s3:::Turbot-test-anonymous"
}

However, if the following condition is added to the statement, then it no longer grants anonymous access:

{
  "Sid": "Restrict access to SNS from 290421329364",
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "s3:GetBucketLocation",
    "s3:ListBucket"
  ],
  "Resource": "arn:aws:s3:::Turbot-test-anonymous",
  "Condition": {
    "ArnEquals": {
      "AWS:SourceArn": [
        "arn:aws:sns:us-east-1:290421329364:*"
      ]
    }
  }
}

Anonymous access can be restricted by using conditions effectively to restrict access to specific ARNs or resources.

If anonymous access is allowed and there is also a condition that allows any source ARN, then the statement is still granting anonymous access:

{
  "Sid": "Allow anonymous access",
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "s3:GetBucketLocation",
    "s3:ListBucket"
  ],
  "Resource": "arn:aws:s3:::Turbot-test-anonymous",
  "Condition": {
    "ArnLike": {
      "AWS:SourceArn": [
        "*"
      ]
    }
  }
}

How do Conditions Affect Anonymous Access?

Currently Turbot evaluates the following conditions:

  • ArnLike (Supports wildcard)
  • ArnEquals (Supports wildcard)
  • StringEquals

A condition block can contain a single condition or a combination of different conditions.

Single Condition

For a statement that allows anonymous access and there exists a single condition using ArnLike, ArnEquals, StringEquals that grants access to *, then that statement is still granting anonymous access.

For instance, even though this policy has an ArnEquals condition, the condition matches against *, so it still allows anonymous access:

{
  "Sid": "Allow anonymous access",
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "s3:GetBucketLocation",
    "s3:ListBucket"
  ],
  "Resource": "arn:aws:s3:::Turbot-test-anonymous",
  "Condition": {
    "ArnEquals": {
      "AWS:SourceArn": [
        "*"
      ]
    }
  }
}

Multiple Conditions

When there are multiple conditions on a policy statement, they are evaluated by AWS as an andtogether.

For instance, even though the following statement grants access to "AWS": "*" and there is a condition matching AWS:SourceArn against *, then ArnLike condition blocks anonymous access:

{
  "Sid": "Allow anonymous access",
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "s3:GetBucketLocation",
    "s3:ListBucket"
  ],
  "Resource": "arn:aws:s3:::Turbot-test-anonymous",
  "Condition": {
    "ArnLike": {
      "AWS:SourceArn": "arn:aws:sns:us-east-1:382937163847:mytopic"
    }
    "ArnEquals": {
      "AWS:SourceArn": [
        "*"
      ]
    }
  }
}

For statements that grant anonymous access in their principals, if any specific resource ARN, e.g., arn:aws:sns:us-east-1:382937163847:mytopic, is specified in an ArnLike or ArnEquals condition, or any AWS account ID is granted in a StringEquals condition, then the statement will not actually grant anonymous access. Even if those statements contain conditions that allow anonymous access, as long as there is one restrictive condition, then they will not grant anonymous access.

Removing Anonymous Access

Using the following S3 bucket policy that allows anonymous access as an example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Example permissions",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ],
        "AWS": [
          "arn:aws:iam::290421329364:root",
          "*"
        ],
        "Federated": [
          "accounts.google.com"
        ]
      },
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::test-anonymous"
    }
  ]
}

If the Turbot anonymous access policy is set to Enforce: Deny anonymous access, then Turbot will remove just the anonymous from the principal field and update the bucket policy to:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Example permissions",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ],
        "AWS": [
          "arn:aws:iam::290421329364:root",
        ],
        "Federated": [
          "accounts.google.com"
        ]
      },
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::test-anonymous"
    }
  ]
}

Restricting Anonymous Access to IAM Roles

Anonymous access to IAM roles can be prevented through AWS > IAM > Role Trust Policy Anonymous Access, which is set to Skip by default. This policy currently supports the following values:

Skip
Check: Deny anonymous access Enforce: Deny anonymous access

Setting the policy value to Enforce: Deny anonymous access will remove any anonymous access in the principal field of each statement. If a statement has no principals after anonymous access has been removed, then the statement will be deleted.

If this would delete all statements from the role trust policy, Turbot will then replace all statements with a single statement that allows the root account ARN permission to assume that role, as a role trust policy cannot be empty or deleted.

Restricting Anonymous Access to S3 Buckets

Anonymous access to S3 buckets can be prevented through AWS > S3 > Bucket Anonymous Access, which is set to Skip by default. This policy currently supports the following values:

Skip
Check: Custom bucket policy does not allow anonymous access (DEPRECATED)
Check: Deny anonymous access
Enforce: Explicitly deny invalid bucket policy statements (DEPRECATED)
Enforce: Deny anonymous access

Note: The following values have been deprecated and will be removed in v5.0.0:

  • Check: Custom bucket policy does not allow anonymous access
  • Enforce: Explicitly deny invalid bucket policy statements

Setting the policy value to Enforce: Deny anonymous access will remove any anonymous access in the principal field of each statement. If a statement has no principals after anonymous access has been removed, then the statement will be deleted. If Turbot deletes statements from the bucket policy and there are no statements left, then the bucket policy will be deleted.

Restricting Anonymous Access to SQS Queues

Anonymous access to SQS queues can be prevented through AWS > SQS > Queue Access Policy Anonymous Access, which is set to Skip by default. This policy currently supports the following values:

Skip
Check: Deny anonymous access
Enforce: Deny anonymous access

Setting the policy value to Enforce: Deny anonymous access will remove any anonymous access in the principal field of each statement. If a statement has no principals after anonymous access has been removed, then the statement will be deleted. If Turbot deletes statements from the queue access policy and there are no statements left, then the queue access policy will be deleted.

Was this article helpful?
0 out of 0 found this helpful