identity-center

AWS Identity Center

Identity Center steht im Mgmt-Account, ist Org-weit verfuegbar. Login-URL fuer Browser + CLI:

https://d-996749743e.awsapps.com/start

Instance

Feld	Wert
Instance ARN	arn:aws:sso:::instance/ssoins-69872311d7798796
Identity Store	d-996749743e
Owner Account	343241684374 (Mgmt)
Erstellt	2026-05-07 13:04

Users

Direkt im Identity Store gepflegt (kein externer IdP wie Entra/Okta).

Username	Display Name	Verwendung
mkuehlmann	Marvin Kuehlmann	Org-Admin, alle Accounts
alex-gross	Alex Gross	Becker-PM, nur av-becker mit BeckerBasOperator

Groups

Keine. Direct user-to-permission-set-assignment. Bei >2 Externen wechseln auf Groups.

Permission Sets

AdministratorAccess

Feld	Wert
ARN	arn:aws:sso:::permissionSet/ssoins-69872311d7798796/ps-69871969f88ab21e
Beschreibung	Full admin access fuer Marvin auf alle Org-Accounts
Session-Duration	8 Stunden
Managed Policies	AdministratorAccess (AWS-managed)
Inline Policies	keine

Zugewiesen: mkuehlmann auf alle 4 Accounts.

BeckerBasOperator

Feld	Wert
ARN	arn:aws:sso:::permissionSet/ssoins-69872311d7798796/ps-9dcb85affd6b874b
Beschreibung	S3-RW (kein Delete) auf bas-twin-data, S3-Read auf bas-twin-artifacts, S3-RW auf bas-twin-data-test, s3:ListAllMyBuckets fuer Console-Ansicht, Bedrock-Invoke fuer eu.anthropic.claude-* Modelle. Kein IAM-Manage, kein Admin.
Session-Duration	8 Stunden

Zugewiesen: alex-gross auf av-becker (084400305827).

Least-Privilege-Pattern: Pro Kunden-PM ein eigenes Permission Set, nur die Buckets + Modelle die er fuer den konkreten Use-Case braucht. Kein Admin, kein IAM-Management.

Login-Flow

Browser: https://d-996749743e.awsapps.com/start → Login → Account waehlen → Permission Set waehlen → Console.

CLI (Daily Driver):

aws sso login --profile mgmt   # 8h-Session, alle Profile in derselben sso-session danach valide
aws --profile becker s3 ls
aws --profile av-prod ec2 describe-instances

MFA: Marvin nutzt 1Password als Authenticator (steht im Identity-Store-User-Profil). Bei Setup eines neuen Externen MFA-Pflicht aktivieren.

Setup eines neuen Externen (z.B. Vibe-Factory-PM, Icking-PM)

1. Identity Center → Users → Add user → vorname-nachname, Email-Adresse, MFA-Pflicht
2. User bekommt Welcome-Mail mit Set-Password-Link
3. Permission Set anlegen: <KundeProjekt>Operator mit Inline-Policy auf genau die Buckets + Modelle die er braucht
4. Account-Assignment: User → Permission Set → genau ein Kunden-Account
5. Login-URL plus Anleitung an User

Niemals dem Kunden-Mitarbeiter AdministratorAccess geben — auch nicht „nur kurz”.

Cross-Org-Zugriff (Icking)

Identity Center managed nur Accounts in der eigenen Org. Der Icking-Account 063507503859 ist in einer fremden Org mit eigenem Identity Center (d-9967562255) — wir koennen ihn nicht in unser Login-Portal binden.

Drei Wege wenn das Konsolidieren irgendwann lohnt:

1. Cross-Account AssumeRole vom Mgmt-User aus — Icking-Admin (Florian) legt eine IAM-Role mit arn:aws:iam::343241684374:user/mkuehlmann als Trusted-Principal an, wir bekommen ein [profile icking-via-mgmt] ohne separaten SSO-Login. Setup ~10 Min, aber Icking-Admin-Aenderung
2. SAML-Federation Identity-Center → Icking-Account — unser Identity Center wird im Icking-Account als External IdP registriert. Sauberer, ~30 Min pro Seite, Florian muss IdP einrichten
3. Status quo: zwei SSO-Sessions parallel — agentic + aicking in ~/.aws/config, CLI nutzt --profile. Browser-Komfort optional via Extension „AWS Extend Switch Roles”. Null Setup-Aufwand

Stand 2026-05-07: Variante 3 — Icking-Zugriff ist heute nur lesend / Pairing mit Florian, Pain-Point niedrig genug.

Was fehlt noch

• MFA-Pflicht erzwingen via Identity-Center-Policy (heute optional pro User)
• AVV mit Anthropic / AWS fuer Bedrock-Nutzung pro Kunde — separater Track, nicht hier
• Audit: regelmaessig (quartalsweise) Permission-Sets durchgehen, nicht-mehr-genutzte zurueckziehen

Related

• _index
• accounts
• zugriffsmodell — generelle Zugriffs-Doktrin