Delegate service account access across projects

You can grant a service account access to resources in a project other than the project where the service account was created.

Before you begin

A service account exists in the source project (Project A). For more information, see Create a service account.
The service account has the appropriate RBAC roles in its owning project. For more information, see Assign RBAC roles to a service account.
In the source project (Project A), you have the project administrator role or a role that includes the service_account:read permission on the service account.
In the target project (Project B), you have the project administrator role or the role_assignment:create permission.

About this task

By default, service accounts are invisible outside their owning project. Cross-project access requires explicit opt-in from administrators in both the source project and the target project. This two-step delegation model prevents accidental cross-project exposure and enables intentional access sharing when a service account needs to interact with multiple projects.

Cross-project delegation follows a strict opt-in model to prevent unintended access:

Visibility is controlled by the source project. The administrator of the project that owns the service account decides which other projects can see it. Without the service_account:read grant, the service account is invisible to other projects.
Permissions are controlled by the target project. The administrator of the target project decides what roles the service account receives in their project. The source project administrator cannot grant permissions in the target project.
Revoking visibility removes cross-project access. If the source project administrator revokes the service_account:read grant, the service account becomes invisible to the target project. Existing role assignments in the target project remain. However, the target project's administrator can no longer discover or manage the service account.

Procedure

As the Project A administrator, grant the service_account:read permission on the service account to the Project B administrator.
Assign a role that includes the service_account:read permission, scoped to Project A, with the Project B administrator as the principal:
```
$ curl -X POST \
    -H "Authorization: Bearer access_token" \
    -H "Content-Type: application/json" \
    -d '{
      "principal_id": "project_b_admin_id",
      "role_name": "role_name",
      "project_id": "project_a_id"
    }' \
    https://orchestrator_host/api/v1/role_assignments
```
Where:
- access_token is the Project A administrator's access token.
- project_b_admin_id is the UUID of the Project B administrator.
- role_name is the name of a role that includes the service_account:read permission.
- project_a_id is the UUID of Project A (the service account's owning project).
- orchestrator_host is the hostname of your automation orchestrator instance.
This step makes the service account visible to Project B's administrator in the principal selection interface. Without this grant, the service account remains invisible to other projects.

Note:

The service_account:read grant controls visibility only. It does not grant the target project any operational permissions on the service account. The Project B administrator cannot modify, disable, or delete the service account.
As the Project B administrator, verify that the service account is visible in the principal selection interface for Project B.

The service account from Project A is now displayed as an available principal when creating role assignments in Project B.
As the Project B administrator, assign project-scoped roles to the service account within Project B:
```
$ curl -X POST \
    -H "Authorization: Bearer access_token" \
    -H "Content-Type: application/json" \
    -d '{
      "principal_id": "service_account_id",
      "role_name": "role_name",
      "project_id": "project_b_id"
    }' \
    https://orchestrator_host/api/v1/role_assignments
```
Where:
- access_token is the Project B administrator's access token.
- service_account_id is the UUID of the service account from Project A.
- role_name is the name of the role to assign in Project B.
- project_b_id is the UUID of Project B.
- orchestrator_host is the hostname of your automation orchestrator instance.
Verify that the service account can now access resources in both Project A and Project B by listing its role assignments:
```
$ curl -H "Authorization: Bearer access_token" \
    "https://orchestrator_host/api/v1/role_assignments?principal_id=service_account_id"
```
The response includes role assignments scoped to both Project A and Project B.