Solving Enterprise Identity Sprawl at 500-Team Scale

Mapping 500+ Teams Across GitHub, JFrog, Terraform Cloud and AWS Accounts

When an organization grows to hundreds of teams, the difficult part is often not configuring any one platform. It is keeping team identity consistent across GitHub, JFrog, Terraform Cloud, and AWS while still allowing each team to work independently.

The core architectural challenge: How do you uniquely map each team across all three SaaS products when teams constantly shift, applications lack unique identifiers in the CMDB, and relying on repository naming conventions inevitably fails?

With thousands of repositories, maintaining repository-by-repository AWS IAM trust policies quickly becomes difficult to operate. A well-designed Internal Developer Platform (IDP) can move that responsibility into an automated provisioning and governance workflow.

The Failure of Naming Conventions

A common first approach is to rely on naming standards—prefixing repositories, JFrog projects, and Terraform workspaces with a team name. That works until teams are reorganized, applications move, or naming conventions drift.

If an authorization model depends on parsing a repository name, those organizational changes become security changes as well. A better approach is to assign each team a stable, centrally governed identifier and use it consistently across the platforms that need to make authorization decisions.

The Solution: Unified Mapping and Custom OIDC Claims

One pattern I use to solve this is a centralized identity mapping strategy built on three pillars:

1. A stable team identifier: Each team receives a unique key that is mapped consistently to its GitHub repositories, JFrog project, and Terraform Cloud project.
2. Organization-level OIDC customization: GitHub’s OIDC subject claim is configured to include the a custom property team_id with a unique value associated the repository to a team. Our automated provisioning process assigns that property to every repository owned by team_id and keeps it under organization-level governance.
3. Scoped trust policies: AWS IAM and downstream SaaS platforms evaluate the customized OIDC sub claim, including the github organization, immutable id, and the team_id, instead of listing line items for each repository owned by the team.

For example, an AWS role can trust a subject pattern containing a team’s key while still allowing that team’s repositories to change names or be added over time. The companion repository examples show the corresponding IAM trust policies and provisioning configuration.

The Architectural Payoff

Anchoring access control to a governed identifier in the OIDC JWT gives each platform a consistent way to distinguish teams:

• GitHub Actions to AWS: AWS IAM roles evaluate the customized token.actions.githubusercontent.com:sub condition key, matching the team_id and limiting deployment privileges to that team’s repositories.
• Artifact Isolation: JFrog project boundaries are enforced cleanly based on the team’s unique identifier.
• State Management: Terraform Cloud workspaces are associated to a project matching the team_id, keeping state management under control.

This approach does not remove governance; it moves governance to the place where repositories are created and managed. A team identifier should be unique, protected from repository-level changes, and treated as a contract. If the identifier changes, the related IAM and SaaS mappings must be updated deliberately.

Are you struggling to secure your OIDC trust policies or manage identity sprawl across enterprise SaaS boundaries?

With over two decades of systems experience, I’m passionate about designing Internal Developer Platforms (IDPs) that build automated security and identity guardrails right into the developer workflow. I’m always looking to connect with other engineering leaders navigating these same scaling bottlenecks. If your team is untangling complex IAM trust relationships or scaling multi-tenant architecture, feel free to reach out—I’m always happy to talk shop and swap architectural strategies.