AWS Principals

Overview

In AWS, a principal refers to an entity that can make requests to perform actions on AWS resources. It plays a crucial role in AWS Identity and Access Management (IAM) and defines who or what is allowed to interact with a service or resource. AWS uses principals to implement access control by ensuring that only authorized entities can access resources.

Principals can be users, roles, services, or applications—anything that can authenticate and obtain permissions to interact with AWS resources. Let’s dive deeper into the types and concepts around AWS principals.

Types of AWS Principals

1. IAM User

2. IAM Role

3. Federated User

4. AWS Service

5. Anonymous User (Unauthenticated Principal)

1. IAM User Principal

• An IAM user is a human identity that is created within the AWS account.

• It typically represents an individual person or an application that requires long-term access to AWS resources.

• IAM users can have access keys, passwords, and multi-factor authentication (MFA) configured to authenticate.

Example Use Case: A DevOps engineer with an IAM user account can interact with the AWS CLI to manage infrastructure.

Example Policy Snippet:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:user/JohnDoe"
  },
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::my-bucket"
}

This policy grants the user JohnDoe permission to list the contents of an S3 bucket.

2. IAM Role Principal

• An IAM role is a temporary identity intended for trusted entities like users, applications, or services that need access to AWS resources.

• Roles are used when short-term access to AWS resources is preferred over long-term credentials.

• Roles can be assumed by other AWS services, users from other accounts, or federated users.

Example Use Case: An EC2 instance assumes a role to read from an S3 bucket without hard-coding credentials.

Example Policy Snippet:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/EC2ReadOnlyRole"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

This policy allows the EC2ReadOnlyRole to read objects from a specific S3 bucket.

3. Federated User Principal

• Federated users are identities from an external identity provider (IdP) such as Microsoft Active Directory, Google Workspace, or Okta. These identities can temporarily assume AWS roles to access resources within AWS.

• AWS supports SAML 2.0 or OIDC-based identity federation.

Example Use Case: An employee signs in via their company's Active Directory and accesses AWS services without a dedicated IAM user account.

Example Policy Snippet:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:saml-provider/Okta"
  },
  "Action": "sts:AssumeRoleWithSAML",
  "Resource": "arn:aws:iam::123456789012:role/S3AccessRole"
}

This policy allows a federated user from Okta to assume the S3AccessRole.

4. AWS Service Principal

• Some AWS services need to interact with other AWS resources on behalf of the user. AWS services like Lambda, EC2, or CodeBuild act as service principals.

• When these services need access to other AWS resources, they assume roles associated with them.

Example Use Case: A Lambda function assumes a role to write logs to CloudWatch or store data in DynamoDB.

Example Policy Snippet:

{
  "Effect": "Allow",
  "Principal": {
    "Service": "lambda.amazonaws.com"
  },
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::123456789012:role/LambdaExecutionRole"
}

This policy allows the Lambda service to assume the LambdaExecutionRole.

5. Anonymous User (Unauthenticated Principal)

• An anonymous user represents any unauthenticated identity—essentially, a request from the internet without any credentials.

• This is commonly seen in public S3 buckets or API Gateway endpoints that do not require authentication.

Example Use Case: A public website is hosted on an S3 bucket, accessible to anyone without authentication.

Example Policy Snippet:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-public-bucket/*"
}

This policy allows anyone (including anonymous users) to read objects from the S3 bucket.

Principal Element in AWS Policies

In AWS IAM policies, the Principal element specifies who the policy applies to. Depending on the use case, the Principal element can reference different types of identities:

• AWS User or Role: AWS key followed by an ARN (Amazon Resource Name).

• Federated User: Federated key referencing an external identity provider.

• Service Principal: Service key representing an AWS service.

• Anonymous User: Using * to indicate any identity (including unauthenticated users).

Example:

"Principal": {
  "AWS": "arn:aws:iam::123456789012:user/JohnDoe"
}

Trust Policies and Principals

• Trust policies define which principals can assume a role or access specific resources.

• They are typically used with IAM roles, allowing other AWS services or users to assume a role and perform actions.

Example Trust Policy for an EC2 role:

code{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This policy allows EC2 instances to assume the role.