Maybe you’ve seen this issue before. In complex organizations where multiple teams share a Spacelift account, spaces often end up with the same name in different branches of the hierarchy, like having a us-east-1 space under both production and staging. Without the ability to customize the subject claim, those spaces produce identical OIDC tokens, making it impossible for cloud providers like AWS, GCP, or Azure to tell them apart and apply the right permissions.

You can now customize the OIDC subject claim that Spacelift includes in tokens generated for cloud provider authentication. Previously, the subject claim was always built from the space slug, which caused a frustrating problem in hierarchical space structures: two spaces in different branches of your organization but with the same name, like /root/production/us-east-1 and /root/staging/us-east-1, would produce identical subject claims. That made it impossible to write cloud provider trust policies that distinguished between them.

The new subject template setting lets you define your own claim format using a set of available placeholders, including {spacePath}, which resolves to the full hierarchical path of the space. This unlocks two things that were not possible before: you can now differentiate between identically-named spaces in different branches, and you can write a single wildcard trust policy that covers an entire branch of your space hierarchy, like all production spaces, without needing to update the policy every time a new space is added. The setting is available in Organization Settings under Security, requires admin access, and comes with a migration guide to help you update existing trust policies without causing authentication failures during the transition.

You can read the full documentation here!