Trusted Access Guardrails

Trusted Access Guardrails

Overview

Trusted Access guardrails allow you to define whom and what you trust and enforce those limitations on your cloud resources. With Guardrails Trusted Access policies, you can define which accounts, services, and organizations are allowed to be granted access your resources. The Trusted Access control can audit or enforce those policies, giving centralized control over trusted boundaries.

Many examples here will list AWS, but these policies also are available for Azure and GCP resources.

Policies and Controls

Trusted Access controls are generally divided into two patterns:

Default Policies

Default policies at the account level allow administrators to define trusted boundaries centrally for all services. However, these can be overrode by either defining resource type specific Trusted Access policies, or by setting an exception for the default policy.

Account-level Defaults

The value for all of the account-level default policies is to allow everything: *

Policy Description
AWS > Account > Trusted Accounts [Default] A list of AWS account IDs
AWS > Account > Trusted Organizations [Default] A list of AWS organization IDs
AWS > Account > Trusted Identity Providers [Default] A list of Identity providers
AWS > Account > Trusted Service [Default] A list of AWS services

Service-level Defaults

The value for all of the service-level default policies is to allow everything: *

Policy Description
AWS > {Service} > Trusted Accounts [Default] A list of AWS account IDs
AWS > {Service} > Trusted Organizations [Default] A list of AWS organization IDs
AWS > {Service} > Trusted Identity Providers [Default] A list of Identity providers
AWS > {Service} > Trusted Service [Default] A list of AWS services

Simple List Pattern

Some resource types allow you to grant access to other accounts.

Guardrails solves this with two policies:

For resources that support cross account access, Guardrails can check or enforce to the list of AWS accounts. These policies can be found directly under the service in the hierarchy:

Example: Trusted Access policies for EC2 Snapshots:

Acceptable Trusted Access policy values are consistent across resource types:

Value Description
Skip Skip - no action taken
Check: Trusted Access > Accounts To check access is granted to the list of trusted accounts
Enforce: Trusted Access > Accounts To enforce, access to non-trusted accounts are removed

IAM Resource Policy Pattern

Many resources allow users to grant access directly on the resource itself via a resource policy. The Trusted Access control will evaluate and modify access granted in said resource policy.

Guardrails allows Trusted Access configurations via this list of policies. Note that while they all exist, is not necessary to configure all of them in order to enforce or check resources for unauthorized access:

These policies can be found under the service in the hierarchy:

Example: S3 Trusted Access policy family:

Again, acceptable Trusted Access policy values are consistent across resource types:

Value Description
Skip Skip - no action taken
Check: Trusted Access To check access is granted to the list of AWS accounts, Organizations, Services, Identity Providers, and OAIs set on the policy
Enforce: Revoke untrusted access To enforce, access to non-trusted members are removed

Note:

Example: AWS > S3 > Bucket > Policy > Trusted Access

First, assume that the bucket policy is trusting the account 123456789210 that is under the organization o-c6v5d4wd43. The identity provider granted access in the bucket policy is www.facebook.com. The service granted access to the bucket via existing bucket policies is ec2.amazonaws.com, and the CloudFront Origin Access Identity with access is defined as E1QK6X5E0FOET6. The following policies have been configured in Guardrails:

In order, these policies will evaluate Accounts, Organization Restriction, and CloudFront Origin Access Identities as trusted, but Identity Providers and Services as untrusted. The policy evaluation will result the control being in the ALARM state.

Sample S3 bucket policy for the above example:

{
  "Version": "2012-10-17",
  "Id": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadAccess",
      "Effect": "Allow",
      "Principal": {
        "Federated": "www.facebook.com"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::bucketexample01"
    },
    {
      "Sid": "WriteAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1QK6X5E0FOET6"
      },
      "Action": "s3:PutBucket",
      "Resource": "arn:aws:s3:::bucketexample01"
    },
    {
      "Sid": "ReadAccess1",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::bucketexample01"
    },
    {
      "Sid": "WriteAccess1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789210:root"
      },
      "Action": "s3:PutBucket",
      "Resource": "arn:aws:s3:::bucketexample01",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-c6v5d4wd43"
        }
      }
    }
  ]
}