gabriel / musehub public
Closed #152 Enhancement production-readiness
filed by gabriel human · 68 days ago

Production readiness — Section 3: Identity, Authentication, and Permissions

0 Anchors
— Blast radius
— Churn 30d
0 Proposals

Full detail

Real build work, deferred per the doc-first sweep. Needed: AWS IAM Identity Center with separate Gabriel/Aaron identities and permission sets, replacing the shared musehub-infra laptop credential with individual or CI-scoped temporary credentials.

Blocked on: broader AWS read access (requested from Gabriel) to audit current IAM state fully before designing the target shape.

◎ Activity3
●
gabriel opened this issue 68 days ago
○
gabriel 68 days ago

Scope update: this section's IAM Identity Center rollout should cover all 5 team members from the start (Gabriel, Aaron, Sol, Toby, Ben), not just Gabriel/Aaron. Target permission sets: Administrator (Gabriel), Operator (Aaron), StagingOperator (interns, staging-only). See docs/production-readiness/runbook-deploy-onboarding.md.

○
gabriel 48 days ago

Reviewed with full detail (03-identity-and-permissions.md + runbook-deploy-onboarding.md).

Human Access — done for Gabriel/Aaron (2026-08-26): IAM Identity Center is live (MuseHub-Workforce, Google Workspace SAML + SCIM). Gabriel and Aaron each have individual identities with AdministratorAccess across all three AWS accounts (Management, Nonproduction, Production). This deliberately supersedes the original scoped Operator + production-approval-gate plan for Aaron — Gabriel upgraded it given Aaron's 50/50 LLC ownership stake and intent to independently own half of infra maintenance.

Deferred, not forgotten: Sol/Toby/Ben's StagingOperator access remains intentionally out of scope — no active timeline for any of them starting yet. Revisit when one of them is actually about to contribute.

Still open (separate from this ticket's human-access scope): the shared musehub-infra long-lived credential is still what deploy/push.sh/deploy/deploy.sh use, and those scripts are still hardcoded to the old pre-rebuild instance. That's tracked under #159.

Also fixed a stale note in the runbook claiming prod deploy was blocked by a missing IAM instance profile on the old instance — that instance no longer exists; production was rebuilt from scratch with a correctly configured instance profile.

Leaving open pending the #159 deploy-credential work.

○
gabriel 38 days ago

Re-verified with full account access — every previously-blocked check now runnable.

Confirmed/resolved:

  • No root access keys on either account (AccountAccessKeysPresent: 0)
  • Root MFA correct across all three accounts per the established centralized-root-access model
  • IAM Identity Center confirmed live and correctly configured
  • Full IAM user inventory for Nonproduction (previously invisible — iam:ListUsers was denied): 5 users found, not the 3 originally assumed
  • Deleted s3-migration-temp — dead leftover, key already inactive, cleaned up entirely
  • Separate staging/production deploy auth confirmed resolved (#150)

New finding, flagged not fixed: stori-admin has full AdministratorAccess to the entire shared Nonproduction account via a static, unrotated key since January — a real risk given this account also hosts staging. Deliberately not touched since it's Stori's credential; needs a conversation with whoever manages their access first.

Remaining work (stori-admin resolution, credential rotation, root-use policy) split to #176.

Closing — the core identity architecture is done and fully verified.

✓
closed this issue 38 days ago