The Challenge of Cloud Identity Governance
Your security team can see every user in your identity provider, and your AWS accounts can provision resources independently. But can anyone tell you which data scientists have access to specific SageMaker domains across multiple accounts and regions?
This isn't just theoretical. AWS IAM Identity Center integrates with external identity providers to centralize authentication and authorization for AWS resources across AWS Organizations. As AWS adds more native integrations, you face a choice: centralize identity governance reporting and enforcement or let each account owner manage their own application assignments.
The debate among practitioners is divided. Some argue centralized visibility is essential for compliance and incident response. Others say centralization creates bottlenecks and doesn't reflect team workflows. Both perspectives have valid points.
Why Centralized Governance Matters
Centralization offers clear benefits: auditability, consistency, and faster incident response.
First, compliance frameworks require comprehensive answers. When auditors ask, "Which users have access to production data processing applications?" you need a complete answer. Manual surveys won't satisfy SOC 2 Type II or ISO/IEC 27001 auditors who expect evidence-based access reviews. The AWS IAM Identity Center APIs provide this data, but only if collected centrally.
Second, decentralized assignment leads to inconsistencies. For example, if Account A names their SageMaker application "SageMaker_Data_GTLabel" and Account B uses "sagemaker-gtlabel-prod," your access reports become confusing. Centralized governance enforces naming patterns like <AWS_Service>_<LOB>_<ENV>_<AppName> and detects violations programmatically.
Third, incident response is faster with centralization. If you discover a compromised identity at 2 AM, you can't wait for multiple account owners to check their application assignments. Automated discovery that generates CSV files for analysis means your team can assess the situation in minutes.
Technically, IAM Identity Center application ARNs use GUIDs, not human-readable names. Without centralized tracking, correlating these GUIDs to business context is cumbersome. This approach works for a few applications but fails at scale.
The Case for Distributed Ownership
The distributed model argues that centralization solves old problems while creating new ones.
Cloud adoption reality: business units provision resources faster than central IT. If your data science team needs a SageMaker domain urgently, requiring central approval for user assignments adds unnecessary friction. The IAM principal creating the resource already needs specific permissions. Why add another approval layer?
The permission model itself resists centralization. Listing Identity Center users or groups requires broad permissions. You can't create a restrictive IAM policy for account owners to see only their team's identities. This means your central team either sees everyone or you build costly custom solutions.
Distributed ownership aligns with how identity governance works in mature organizations. Application owners know which groups need access and understand the business context. Centralizing reporting doesn't mean centralizing provisioning. You can collect assignment data centrally while leaving create/delete actions to those with context.
Operationally, centralized teams can become bottlenecks. If your central identity governance team is overwhelmed, routine application assignments pile up. Distributed ownership with centralized visibility provides auditability without creating dependencies.
A Practical Hybrid Approach
Most organizations adopt a hybrid model: centralize discovery and reporting while distributing assignment authority within set guidelines.
The pattern: enable delegated administration for Identity Center within the AWS organization. Restrict IAM principals that can create applications using service control policies. Enforce naming conventions through tools like Open Policy Agent or Checkov. Automate continuous discovery of applications and assignments across all accounts and regions.
This approach answers compliance questions without forcing every assignment through a central queue. Automated discovery generates queryable output and CSV files for audits. Security teams gain visibility, and account owners maintain agility.
Naming conventions become the contract. Define IdP groups as AWS_<ACCT#>_<AWS_Service>_<LOB>_<ENV>_<AppName> and Identity Center applications similarly. This allows reporting to map assignments to business context programmatically. Violations appear in your discovery output.
Our Recommendation
Centralize visibility and enforcement patterns. Distribute provisioning authority to account owners who follow those patterns.
The architecture of IAM Identity Center makes full centralization impractical. The GUID-based ARNs, broad permissions, and integration with account-specific resources suggest distributed ownership. But compliance and incident response needs are real. You can't answer "who has access" with "check with multiple account owners."
Invest in automated discovery and reporting. Define clear naming conventions and enforce them through policy-as-code at resource creation. Track application assignments continuously so your security team can query access without relying on account owners. Generate audit evidence automatically rather than during reviews.
The challenge isn't the tools. It's getting security, governance, application teams, and business units to agree on naming patterns and approval workflows before inconsistencies arise. Start that conversation now, before the next audit.
