Currently, integrating external systems with Harness requires the creation and management of dedicated service accounts and API tokens. This approach introduces overhead and complexity, especially when scaling across multiple systems and scopes.

We propose enabling Harness to accept and evaluate OIDC claims as a means of authorizing activity within the platform. This would allow external systems to authenticate using OIDC and perform actions in Harness based on the claims presented in their identity token—eliminating the need for static service accounts and API tokens.

Example Use Cases:

Different workspaces could present OIDC claims that map to varying levels of access:

One workspace might request account-wide admin permissions.

Another might request admin rights scoped to a specific org or project.

A third might request narrowly scoped permissions, such as provisioning a specific entity type.

Systems like Dynatrace could trigger recovery pipelines in response to faults, using OIDC claims to prove identity and scope. For example, a claim tied to application_x would allow execution of recovery pipelines for that app only—while being denied access to pipelines for other applications.

Proposed Enhancements:

Introduce a mechanism to map OIDC claims directly to Harness role bindings, similar to how service accounts are currently mapped. This would allow dynamic, context-aware authorization without requiring pre-provisioned service accounts.

Claims should support scoping by:

Account, org, and project identifiers

Entity types (e.g., pipelines, environments, services)

Contextual metadata (e.g., workspace name, application ID)

Security and Auditability:

All actions performed via OIDC-based access should be fully auditable, with clear traceability of the identity and claims used.

Benefits:

Reduces operational overhead by eliminating static service account management.

Enables secure, scalable, and context-aware automation.

Aligns with modern identity federation and zero-trust principles.