What is an AWS Principal?

Definition

An AWS Principal is the entity that makes a request to AWS. Every API call has a principal: a user, an assumed role, a federated identity, or an AWS service acting on your behalf.

Principals are referenced in trust policies and resource-based policies to define who can do what.

In simple terms:

A principal is the "who" in any AWS authorization decision.

---

Why Principals Matter

• Authorization always starts with "which principal is asking?"
• Resource-based and trust policies grant access by referencing principals.
• Misreferenced principals (*, broad accounts, missing external IDs) are common sources of unintended access.
• Cross-account access requires principals to be carefully named.

---

Principal Types

1. AWS Account / Root User

• The owning account itself, ARN: arn:aws:iam::123456789012:root.
• When referenced in a policy as Principal: { "AWS": "arn:aws:iam::123456789012:root" }, it means "any IAM principal in account 123456789012 that's authorized via identity-based policy."
• Direct use of root user for actions is strongly discouraged.

2. IAM User

• arn:aws:iam::123456789012:user/JaneDoe
• Long-lived identity with credentials.

3. IAM Role (and Assumed Role)

• Role ARN: arn:aws:iam::123456789012:role/MyRole
• Assumed-role session ARN: arn:aws:sts::123456789012:assumed-role/MyRole/session-name
• Roles are assumed; the resulting session is also a principal during its lifetime.

4. Federated User

• SAML or OIDC federated principal.
• In trust policies referenced via federation provider:
  • Federated: "arn:aws:iam::123456789012:saml-provider/Okta"
  • Federated: "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"

5. AWS Service

• Service: "lambda.amazonaws.com" — used in trust policies so a service can assume the role.
• Common values: ec2.amazonaws.com, s3.amazonaws.com, lambda.amazonaws.com, eks.amazonaws.com, etc.

6. Anonymous (Public)

• Principal: "*" — anyone, including unauthenticated.
• Used (carefully) for truly public resources.

7. Canonical User

• Legacy S3 cross-account references; rarely needed in modern setups.

---

How Principals Appear in Policies

Trust Policy (Role)

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

Resource Policy (S3 Bucket)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::shared-bucket/*"
  }]
}

Public Access (S3)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::public-website/*"
  }]
}

Identity Policy (no Principal — implicit)

Identity-based policies don't name a principal — they apply to whoever they're attached to.

---

Common Principal Mistakes

• Principal: "*" on sensitive resources. Public exposure.
• AWS: "*" cross-account trust. Anyone in any account can assume.
• Broad account references (AWS: "arn:aws:iam::PARTNER-ACCOUNT:root") without external ID — Confused Deputy.
• Trust policy with stale principal (deleted user / role still listed).
• No condition on principal — service principals trusted unconditionally (e.g., lambda.amazonaws.com allowed to assume a role with no aws:SourceArn).

---

Real-World Examples

1. Public S3 Bucket Leak

Bucket policy with Principal: "*" on s3:GetObject — millions of files exposed publicly. One of the most common AWS data exposure patterns.

2. Confused Deputy Cross-Account

A vendor's role trusts the vendor's main AWS account. Every customer of the vendor can assume that role and reach your resources via the vendor — until you require an external ID.

3. Service Trust Without Condition

A role trusts s3.amazonaws.com so S3 can write logs. Without aws:SourceArn condition, any S3 bucket in AWS could trigger this role action — Confused Deputy via service.

4. Trust Policy Privilege Escalation

A role's trust policy includes Principal: "*" (overly broad). Anyone with permission to assume can pivot in.

---

Best Practices

1. Be specific. Reference exact ARNs, not * or root.
2. Use external IDs in cross-account trust policies for third parties.
3. Use conditions (aws:SourceArn, aws:SourceAccount, aws:PrincipalOrgID) on service trust to prevent Confused Deputy.
4. Restrict resource policies with aws:PrincipalOrgID for org-internal access.
5. Federate instead of creating per-person IAM users.
6. Tag principals with owner / purpose where supported.
7. Periodic review of trust and resource policies.
8. IAM Access Analyzer for unintended principal exposure.
9. Block Public Access for S3 to prevent accidental * principal exposure.
10. Detect policy changes that broaden principal lists.

---

Checklist

• No Principal: "*" on sensitive resources?
• Cross-account trust uses external ID where appropriate?
• Service trust includes aws:SourceArn / aws:SourceAccount / aws:PrincipalOrgID conditions?
• Identity Center or federation used in lieu of IAM users?
• IAM Access Analyzer enabled?
• S3 Block Public Access on?
• Detection on trust/resource policy changes?
• Quarterly review of trust relationships?

---

How Forestall Helps

Forestall enumerates principals across accounts and shows their effective reach:

• Cross-account trust map.
• Public/cross-account exposure via resource policies.
• Risky service trust patterns.
• Principals with paths to high-value data.

---

Frequently Asked Questions

Is "Principal" the same as "user"?

No — principal is broader; users, roles, services, federated identities are all principal types.

What does Principal: { "AWS": "arn:aws:iam::123:root" } mean?

"Any IAM principal in account 123 that is authorized via identity-based policy." Not literally the root user only.

Can I use wildcards in Principal?

Principal: "*" is valid (public). Wildcard substring matching in Principal ARNs is not supported the way it is in Resource.

What's aws:SourceArn?

A condition key referring to the source resource ARN that triggered the request — used to prevent Confused Deputy in service trust.

Is root literally the root user?

arn:aws:iam::ACCOUNT:root in Principal context refers to "the entire account" rather than the literal root user.

---

Conclusion

The AWS Principal is the "who" of every AWS request. Naming principals precisely — and avoiding *, broad accounts, and unconstrained service trust — is fundamental to safe IAM design. Combined with external IDs, organization-scoped conditions, and continuous monitoring, principal hygiene closes a large fraction of cloud identity risk.