IAM Policies vs Identity Center Permission Sets

DotID provides two distinct but related authorization layers: IAM Policies (managed in AdminCenter) and Permission Sets (managed in Identity Center). Understanding the difference is essential for designing access control across the FlexGalaxy.AI platform.

Overview

	IAM Policies (AdminCenter)	Permission Sets (Identity Center)
Scope	Single account	Organization-wide (cross-account)
Target principals	IAM users and groups (service identities)	IDC users and groups (real people)
Managed in	AdminCenter (console.flexgalaxy.com/admincenter/)	Org Console (console.flexgalaxy.com/orgs/)
Access model	Direct attachment to users/groups	Account Assignments (Group + Permission Set + Account)
Credential type	Access keys (long-lived, programmatic)	Temporary session credentials (short-lived, federated)
Use case	Service-to-service API access within one account	People accessing multiple accounts via the console

IAM Policies (AdminCenter)

IAM Policies live inside a single account and control what IAM users (service identities) and IAM groups can do within that account.

Key concepts:

• Managed Policies — reusable, named policy documents that can be attached to multiple users or groups. Platform-managed policies (e.g. AdministratorAccess) are read-only. See Managed Policy Sets.

• Inline Policies — policy documents embedded directly on a specific user or group. Not reusable, but useful for one-off permissions.

• Permission Boundaries — an advanced guardrail that sets the maximum permissions an IAM user or group can have, regardless of their attached policies.

Think of IAM Policies as answering:

“What can this service user do inside my account?”

Permission Sets (Identity Center)

Permission Sets belong to the organization and control what IDC users (real people) can do when they access any member account.

A Permission Set is a bundle of IAM policies. For example, the AdministratorAccess permission set contains the AdministratorAccess managed IAM policy.

Permission Sets are not attached to users directly. Instead, they are granted through Account Assignments:

Account Assignment = IDC Group + Permission Set + Target Account

Example:
  Group "Platform Admins"
    + Permission Set "AdministratorAccess"
    + Account "Production"
    ────────────────────────────
    = Members of "Platform Admins" get full admin access
      when they access the "Production" account

Think of Permission Sets as answering:

“What can this person do when they access that account?”

How They Relate

Permission Sets and IAM Policies are connected, not independent:

Organization Level (Identity Center)
┌──────────────────────────────────────────────────────┐
│  Permission Set: "ReadOnlyAccess"                    │
│    ├── IAMReadOnlyAccess          (managed policy)   │
│    ├── OrganizationReadOnlyAccess (managed policy)   │
│    ├── AuditReadOnlyAccess        (managed policy)   │
│    └── QuotaCenterReadOnlyAccess  (managed policy)   │
│                                                      │
│  Account Assignment:                                 │
│    IDC Group "Auditors" ──┐                          │
│    Permission Set ────────┤                          │
│    Account "Production" ──┘                          │
└──────────────────────────────────────────────────────┘

Account Level (AdminCenter)
┌──────────────────────────────────────────────────────┐
│  IAM User: "ci-deploy-bot"                           │
│    ├── Attached: AdministratorAccess (managed policy) │
│    └── Inline: custom deploy permissions             │
│                                                      │
│  IAM Group: "monitoring-agents"                      │
│    └── Attached: AuditReadOnlyAccess (managed policy) │
└──────────────────────────────────────────────────────┘

The same managed IAM policies (e.g. AdministratorAccess, AuditReadOnlyAccess) appear in both layers:

• In AdminCenter, they are attached directly to IAM users/groups.

• In Identity Center, they are bundled inside Permission Sets, which are then assigned to IDC groups via Account Assignments.

Platform-Managed vs Customer-Managed

Both layers distinguish between platform-managed and customer-managed resources:

	Platform-Managed	Customer-Managed
Created by	Platform (provisioned automatically)	Account administrator
Editable	No (read-only)	Yes
Deletable	No	Yes
Examples	AdministratorAccess, IAMFullAccess, ReadOnlyAccess	DeveloperAccess, custom permission sets

Platform-managed resources use the sentinel PLATFORM account (00000000-0000-0000-0000-000000000000) as their owner and are provisioned by the platform. See Managed Policy Sets for the full list.

AWS Analogy

For those familiar with AWS:

Concept	AWS Equivalent	FlexGalaxy
IAM Policy	AWS IAM Policy	IAM Policy (AdminCenter)
IAM User	AWS IAM User	IAM User (service identity)
Permission Set	IAM Identity Center Permission Set	Permission Set (Identity Center)
Account Assignment	Account Assignment	Account Assignment
IDC User	IAM Identity Center User	IDC User (real person)
AWS Managed Policy	arn:aws:iam::aws:policy/...	Platform-managed policy (is_managed = true)