Managing Pipeline Identity in Refinery Studio
Refinery Studio makes a pipeline's identity visible and manageable where you already work — on the adapter, on the pipeline, and on the service-account configuration itself. This page walks through what you see and what you can do.
On the adapter — the Pipeline Service Account panel
Open an adapter's edit form and you will find a Pipeline Service Account section. It shows the identity that all of the adapter's pipelines use by default:
- the linked Configuration and the Client it authenticates as,
- the roles the account carries (shown as chips), and
- how widely it is used — "Default for N of M pipeline(s)".
If nothing is linked, the panel shows a clear danger notice: "No pipeline service account is linked — the deploy guard will refuse every pipeline on this adapter. Link a configuration here or set a per-pipeline override." This is the same rule described in Service Accounts — the panel simply surfaces it before you try to deploy.
Rotate Secret
The panel has a Rotate Secret action that issues a fresh client secret for the pipeline service account. Because the old secret stops working immediately, the adapter keeps using it until its data flows are redeployed — so Studio confirms the action and, once the new secret is issued, offers a Deploy data flows button to roll it out right away.
Rotation only applies to accounts that use an explicit secret. Accounts that work by impersonation have no secret to rotate (see Service Accounts → The secret is optional); Studio shows their credential mode as "impersonation via adapter credentials" instead of "secret-based".
On the pipeline — the Execution Identity block
When you edit a pipeline (data flow), its properties panel includes an Execution Identity block that tells you, at a glance, who this pipeline runs as. It shows one of three states:
| State | Chip | Meaning |
|---|---|---|
| Inherited | Inherited from adapter | The pipeline uses the adapter's default service account |
| Override | Override | The pipeline has its own linked service account, which wins over the adapter default |
| Unresolved | danger notice | No identity can be resolved — deploying this pipeline will be refused |
Alongside the state you see the identity's role chips and a live health summary (see below). From here you can:
- Override… — link a dedicated service account to just this pipeline (for broader or narrower access than its siblings), or
- Revert to adapter default — remove the override and fall back to the adapter's account.
If the identity is unresolved, the block links straight to the adapter so you can fix the default in one hop.
On the configuration — Usage & identity
Open a service-account configuration and its Usage & identity panel answers "where is this account used, and what is it?":
- Default for — the adapters that use it as their default, and
- Override for — the individual pipelines that link it as an override,
together with the linked Client and its roles. Accounts that were installed by a blueprint are marked app-managed and their core fields are read-only, so you do not accidentally edit something the blueprint owns.
Health at a glance
Everywhere an identity appears — the adapter panel, the execution-identity block, and the configuration details — Studio shows a small set of health badges that are fetched live each time. The overall state is one of healthy, unhealthy, or health unknown, and the individual checks cover:
| Check | What it confirms |
|---|---|
| Client | The identity client exists in the tenant |
| Secret | A usable secret is present (for secret-based accounts) |
| Roles | The account's roles match its declaration — Missing and Superfluous roles are listed if they drift |
| Tenant | The account points at the right tenant |
| Issuer | The account points at the right installation |
| Delegation | On-behalf-of is correctly set up when the account allows delegation |
| Impersonation | The impersonation link is present for secret-less accounts |
health unknown usually means the Identity Service could not be reached at that moment, not that something is broken.
Required-rights analysis
How do you know which roles a service account actually needs? The Analyze required rights action works it out for you. It walks the adapter's (or a single pipeline's) definitions on the server, collects every protected data type the pipelines touch, and joins that against the tenant's data permissions to recommend the roles that would grant the needed access.
The result is presented as a delta against the account's current declaration:
- "declaration covers all touched types" when nothing is missing, or
- grouped Missing and Superfluous role chips when it does not, plus a Baseline group for roles every pipeline account needs.
It also flags the tricky cases honestly: owner-scoped types are called out because a service account needs a full-scope grant for them or it stays blind (see Service Accounts → Roles decide what a pipeline can access), and types whose identity is only known at runtime are listed separately as not statically analyzable.
Required-rights analysis is a recommendation. It shows you what to grant; you still assign the roles deliberately.
Administrative tasks: reconcile and health
Two capabilities exist for administrators beyond the day-to-day panels above.
- Reconcile materializes or repairs a service account from its declaration: it makes sure the identity client exists, converges the issuer and tenant, issues a secret only if one is missing, and syncs the roles, delegation, and impersonation links to match. Reconcile runs automatically after a blueprint is applied and when a tenant is set up, so blueprint-provisioned accounts are kept correct without manual steps. Materializing roles for a service account is gated on the UserManagement role, since it can change what an identity is allowed to do.
- Health can be read on demand (it is the same data the Studio badges show): is the client present, is a secret set, do the roles match the declaration, is the tenant right, and — for secret-less accounts — is the impersonation link in place.