Purpose
Section titled “Purpose”IAM ensures that every action on the platform is attributable, authorized, and aligned with enterprise security requirements.
For migration landing zones, IAM is the control backbone that connects human identities, machine identities, and authorization rules into one governable operating model.
Core IAM building blocks
Section titled “Core IAM building blocks”- Access and Identity (central domain): Use the platform domain as the central reference for IAM capabilities and operating responsibilities. Documentation
- STACKIT IDP: Use STACKIT IDP as the identity control point for authentication and account access flows. Documentation
- Federation (SAML 2.0): Integrate enterprise identities through federation to enforce central identity lifecycle and reduce local account sprawl. Documentation
- Roles and Permissions: Define role-based authorization boundaries for platform teams, application teams, and operations. Documentation
- Custom Roles: Implement least-privilege patterns when default roles are too broad for enterprise controls. Documentation
- Service Accounts: Separate machine identities from user identities for automation, CI/CD, and operational integrations. Documentation
How these elements work together
Section titled “How these elements work together”- Identity source and trust: STACKIT IDP plus federation establish who is authenticated and under which enterprise identity policies.
- Authorization model: Roles and Permissions define who can do what in each governance scope.
- Least-privilege refinement: Custom Roles close permission gaps where standard roles do not match enterprise separation-of-duties requirements.
- Automation identity model: Service Accounts provide non-human identities for repeatable operations without exposing personal credentials.
Key design decisions
Section titled “Key design decisions”- Identity integration approach: Decide how enterprise identity is federated and how lifecycle events are synchronized.
- Role architecture per scope: Design role boundaries for platform, security, operations, and application teams.
- Custom role strategy: Define when custom roles are required and how they are reviewed and approved.
- Privileged access controls: Define approval workflows, temporary elevation, and emergency access handling.
- Service-account governance: Standardize creation, ownership, credential rotation, and traceability for machine identities.
Typical outputs
Section titled “Typical outputs”- IAM architecture baseline: Federated authentication model with documented trust boundaries.
- Role and permission matrix: Standard and custom role mapping per organizational scope.
- Service identity standard: Guardrails for Service Accounts in automation and platform operations.
- Operational IAM run model: Procedures for privileged access, approvals, and emergency access.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- No federation strategy: Local identity silos and inconsistent lifecycle handling.
- Over-privileged default roles: Broad permissions used without custom least-privilege controls.
- Shared privileged users: Administrative actions cannot be attributed to a single accountable identity.
- Automation with human identities: Pipelines and integrations run under personal accounts instead of Service Accounts.