# Section 3 — Identity, Authentication, and Permissions

> Companion to [`musehub-production-readiness-checklist.md`](../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`](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
- [x] IAM Identity Center set up (instance `MuseHub-Workforce`), with Google Workspace as the
  external identity source via SAML and SCIM autoprovisioning. Gabriel and Aaron each have
  individual identities with Google-managed MFA, and are assigned `AdministratorAccess` across
  all three accounts (Management, Nonproduction, Production) as of 2026-08-26.
  - This supersedes the original plan below of giving Aaron a scoped `Operator` permission set
    with a production approval gate. Gabriel made a deliberate, informed decision to give Aaron
    full `AdministratorAccess` instead, given Aaron's actual 50/50 ownership stake in the MuseHub
    LLCs and the intent for him to independently own half of infrastructure maintenance — not an
    oversight or scope-creep.
  - Sol, Toby, and Ben's `StagingOperator` (staging-only, no production) access remains
    **intentionally deferred** — no active need or timeline for it yet. Revisit when any of them
    is actually about to start contributing; see `runbook-deploy-onboarding.md`.
- This resolves Section 1's blocked "Aaron can operate independently" test for AWS console access
  specifically. Deploy-script credential access (the `musehub-infra` shared key) is a separate,
  still-open item — see Workload Access below.

### 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).