Section 3 — Identity, Authentication, and Permissions

Companion to musehub-production-readiness-checklist.md. Workflow note: per Gabriel's direction, this sweep is document-gaps-now / build-later — no IAM Identity Center setup, no new roles, no policy changes performed in this pass. Real access-control work (Section 3's actual point) happens in a follow-up pass once all 20 sections have been surveyed.

⚠️ Scope update (2026-08-08): design this section's IAM Identity Center rollout for all 5 team members from the start (Gabriel, Aaron, Sol, Toby, Ben), not just Gabriel/Aaron — per Gabriel's decision. Target permission sets, per runbook-deploy-onboarding.md: Administrator (Gabriel), Operator (Aaron — staging + production), StagingOperator (Sol/Toby/Ben — staging only, no production access). This is now the concrete reason Section 3 can't stay deferred too long: the interns have no path to real, individual staging access until this ships.

Verified today

• Three IAM users exist in the account (all discoverable only because they're configured as local CLI profiles, not because IAM list access works): musehub-infra, musehub-app, stori-assets-app. I cannot enumerate IAM account-wide — iam:ListUsers/ListRoles are denied for all three. There may be more users/roles I can't see.
• musehub-infra — the deploy credential. Confirmed narrowly scoped: denied on all of iam:*, sso:*, route53:*, cloudtrail:*, guardduty:*, budgets:*, cloudfront:*, wafv2:*, ecr:DescribeRepositories. Allowed: EC2 describe, SSM send/get-parameter (scoped to /musehub/*), ECR push/describe-images, S3 list-buckets. This is workload-style access, but it's used as a shared human credential today (see Section 1) — that's the actual problem, not the scoping itself.
• musehub-app and stori-assets-app exist as separate app-specific users — I have not inspected their attached policies (would need iam:ListAttachedUserPolicies, which is denied). Worth Gabriel confirming these are scoped per-app rather than broad.
• No IAM Identity Center visibility — sso-admin list-instances denied. Cannot confirm from here whether Gabriel and Aaron have separate human AWS identities today, or whether both use root/shared credentials for console access.

What this section actually requires (not yet done)

Every item below is real infrastructure/identity work, correctly deferred per this pass's scope:

Root and Recovery Access

• [ ] Root MFA, no root access keys, root email MFA, root recovery info, documented legitimate root uses, multi-person root approval — all need Gabriel checking/configuring directly in the AWS console. None of this is visible or actionable from CLI credentials.

Human Access

• [ ] IAM Identity Center setup, separate Gabriel/Aaron identities, MFA, permission sets (Administrator/ProductionOperator/Developer/ReadOnly/Billing) — none of this exists yet as far as I can tell, and I can't build it without IAM write access, which is explicitly out of scope for this pass anyway.
• This is the actual fix for Section 1's blocked "Aaron can operate independently" test — flagging the dependency again since it's the concrete reason that test can't pass yet.

Workload Access

• [x] Every service already has its own IAM user (musehub-infra, musehub-app, stori-assets-app) — no shared workload credential across services.
• [ ] AWS keys in source code / GitHub secrets — grep found no AWS keys committed in ~/ecosystem/musehub source. GitHub isn't used for CI here anyway (see Decision Log), so "don't put keys in GitHub secrets" is moot — the relevant equivalent (don't put keys in MuseHub-runner CI config) needs checking once Section 9 designs the actual CI wiring.
• [ ] Deployment role restricted to correct repo/branch/account/resources — not applicable yet, there is no automated deployment role at all; deploys use a human running musehub-infra credentials from a laptop (Section 1 risk, repeated here because it's the same root cause).
• [ ] Separate staging/production deployment roles — not done; both environments currently share the same musehub-infra credential.
• [ ] Temporary credentials everywhere — not done; all current credentials are long-lived IAM user access keys, not STS-issued temporary credentials.

Blocked checks (need broader read access, per your decision to grant it)

Once musehub-infra (or a new audit profile) has read access to IAM/CloudTrail/GuardDuty/Route53/ budgets, I still need to run:

• aws iam list-users / list-roles / list-policies — full account inventory
• aws iam list-attached-user-policies --user-name musehub-app and same for stori-assets-app
• aws sso-admin list-instances — confirm Identity Center state
• Root account MFA/access-key status generally isn't queryable even with ReadOnlyAccess (requires console or aws iam get-account-summary for aggregate counts) — this one may still need Gabriel checking directly regardless of what's granted.

Recommended target shape (for the later build pass)

Given the account is small (3 workload users, 2 people), a lightweight version of the checklist's recommendation is enough — this isn't a large org:

1. IAM Identity Center with two permission sets: Administrator (Gabriel, break-glass only) and Operator (Gabriel + Aaron, day-to-day: EC2/SSM/ECR/S3/logs read+deploy actions, no IAM/billing).
2. Replace the shared musehub-infra laptop credential with either (a) individual STS-assumed roles for Gabriel and Aaron once Identity Center exists, or (b) a CI-only role once Section 9-11 automation exists — ideally both, with the human laptop credential retired entirely.
3. Keep musehub-app and stori-assets-app as-is if they're already scoped per-service (needs confirming once broader read access lands).