vault: integrate linking service identity resolution by prashantkumar1982 · Pull Request #21715 · smartcontractkit/chainlink

prashantkumar1982 · 2026-03-26T06:47:51Z

Summary

Integrates Vault with the linking service flow so workflow-driven Vault requests can carry both OrgId and WorkflowOwner.

The workflow engine now propagates OrgID through RequestMetadata and forwards it into Vault GetSecretsRequest payloads. That OrgID forwarding is gated by VaultOrgIdAsSecretOwnerEnabled, so when the gate is disabled the workflow side omits OrgID.

On the Vault capability side, all gateway request paths (create, update, delete, and list) go through the linker layer. The linker resolves or verifies the org_id / workflow_owner pair and rejects requests when the values do not match correctly.

Execute(GetSecrets) is kept simpler: it treats the incoming GetSecretsRequest identity fields as trusted and validates secret owners against the request WorkflowOwner directly.

github-actions · 2026-03-26T06:48:07Z

👋 prashantkumar1982, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

github-actions · 2026-03-26T06:49:01Z

I see you updated files related to core. Please run make gocs in the root directory to add a changeset as well as in the text include at least one of the following tags:

#added For any new functionality added.
#breaking_change For any functionality that requires manual action for the node to boot.
#bugfix For bug fixes.
#changed For any change to the existing functionality.
#db_update For any feature that introduces updates to database schema.
#deprecation_notice For any upcoming deprecation functionality.
#internal For changesets that need to be excluded from the final changelog.
#nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
#removed For any functionality/config that is removed.
#updated For any functionality that is updated.
#wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

github-actions · 2026-03-26T06:49:09Z

✅ No conflicts with other open PRs targeting develop

trunk-io · 2026-03-26T07:00:21Z

_{View Full Report ↗︎ ⋅ Docs}

github-actions · 2026-03-26T08:08:31Z

CORA - Pending Reviewers

All codeowners have approved! ✅

For more details, see the full review summary.

ibrajer · 2026-03-27T11:35:34Z

core/capabilities/vault/capability.go

+				s.lggr.Errorw("get secrets request owner mismatch", "index", idx, "secretOwner", req.Id.Owner, "orgID", resolvedIdentity.OrgID)
+				return capabilities.CapabilityResponse{}, fmt.Errorf("secret identifier owner %q does not match org_id %q at index %d", req.Id.Owner, resolvedIdentity.OrgID, idx)
+			}
+		case req.Id.Owner != "":


Should this case go first? All other ones depend on it

No, this case means both workflow and orgID were set as nil in the request, which should never happen.
This is just a saniuty check condition.

I think this also allows all to be empty though, I think we should just put a default clause here

i.e. either owner or org ID is non-empty, or we error (nothing else is allowed)

ibrajer · 2026-03-27T11:38:29Z

core/capabilities/vault/capability.go

+				return capabilities.CapabilityResponse{}, fmt.Errorf("secret identifier owner %q does not match workflow owner %q at index %d", req.Id.Owner, resolvedIdentity.WorkflowOwner, idx)
+			}
+		case resolvedIdentity.OrgID != "":
+			if req.Id.Owner != resolvedIdentity.OrgID {


I'm trying to understand the difference between case normalizedWorkflowOwner != "" and case resolvedIdentity.OrgID != "". Is there any case when both the normalizedWorkflowOwner and resolvedIdentity.OrgID are non-empty?

Well, I see this logic is pretty convoluted.
This code path is within Execute(), meaning it will only be called from a workflow, while fetching secrets via GetSecret().
So CLI will never use this code path.

This call is already trusted because comes from within workflow engine with F+1 consensus.

Now, the workflow engine, for a given request, will have both workflowOwner and OrgID. Today, it only sends the workflowOwner, but I am considering it can send both workflowOwner and orgID. This will be helpful for the time we are in auto-migration mode.

So theoretically we don't need linking service to be even invoked for this code path, as we trust inputs here.
@cedric-cordenier what do you think? Should we invoke Linking Service for each GetSecret() path and validate the mapping?
I think it adds extra rpc for each read call, whicih you wanted to avoid?

Yes I don't think we need to invoke the linking service here, we should be able to trust the input coming from the engine if we land in this part of the code

ibrajer · 2026-03-27T11:42:16Z

core/capabilities/vault/org_id_to_workflow_owner_linker.go

+		if workflowOwner == "" {
+			return LinkedVaultRequestIdentity{OrgID: orgID, WorkflowOwner: workflowOwner}, nil
+		}


This can probably be extracted as an independent condition about this if statement, because it will be checked again on L95.

cedric-cordenier · 2026-04-02T09:17:05Z

core/capabilities/vault/capability.go

-
-		if req.Id != nil && normalizeOwner(req.Id.Owner) != normalizedWorkflowOwner {
-			return capabilities.CapabilityResponse{}, fmt.Errorf("secret identifier owner %q does not match workflow owner %q at index %d", req.Id.Owner, request.Metadata.WorkflowOwner, idx)
+		if req.Id != nil && normalizeOwner(req.Id.Owner) != normalizeOwner(r.WorkflowOwner) {


It's safer to use the request.Metadata.WorkflowOwner because that is always provided by the engine; I think using the request.WorkflowOwner is fine because we provide that in the SecretsFetcher (but please check!) but that might change in the future.

Well this method Execute() is only called by the workflows, and they will set this field after picking it up from request.Metadata.WorkflowOwner. So it is the same thing imo.
But still switching to request.Metadata.WorkflowOwner.

cedric-cordenier · 2026-04-02T09:18:04Z

core/capabilities/vault/org_id_to_workflow_owner_linker.go

+	if strings.TrimSpace(resolvedOrgID) == "" {
+		return LinkedVaultRequestIdentity{}, fmt.Errorf("resolved empty org_id for workflow owner %q", workflowOwner)
+	}
+


🤔 Why are we fetching the orgID here? Does this duplicate what we're doing on line 86?

ya, refactored now

cedric-cordenier · 2026-04-02T09:24:09Z

core/capabilities/vault/org_id_to_workflow_owner_linker.go

+}
+
+// Link resolves or verifies the request identity from the caller-provided org and workflow owner.
+func (l *OrgIDToWorkflowOwnerLinker) Link(ctx context.Context, orgID string, workflowOwner string) (LinkedVaultRequestIdentity, error) {


Can we clean up some of the defensive coding throughout this file? I think we've taken it way too far.

see line 53 -- vaultOrgIDAsSecretOwnerEnabled will not be nil if created via the constructor since we'll error if that the case. Same with checking l == nil and the orgResolver; let's just do this check once in the constructor if we need to.

At the moment it's very difficult to understand what the important error conditions are and what we're trying to guard

agreed. cleaned up the fn now.

core/services/workflows/v2/capability_executor.go

core/services/workflows/v2/engine.go

cedric-cordenier · 2026-04-02T09:34:07Z

core/services/workflows/v2/secrets.go

 	return common.HexToAddress(owner).Hex(), nil
 }

+func vaultOrgIDAsSecretOwnerEnabled(ctx context.Context, gate limits.GateLimiter) (bool, error) {


nit: maybe LimitOrFalse since there's nothing vault specific about this, it's a helper

cedric-cordenier · 2026-04-02T09:37:18Z

core/services/workflows/v2/secrets.go

@@ -66,15 +70,18 @@ func NewSecretsFetcher(
 	lggr = logger.Named(lggr, "WorkflowEngine.SecretsFetcher")
 	lggr = logger.With(lggr, "workflowID", workflowID, "workflowName", workflowName, "workflowOwner", workflowOwner, "phaseID", phaseID)


Worth adding the orgID here :) ?

core/scripts/go.mod

core/scripts/cre/environment/examples/workflows/v1/proof-of-reserve/cron-based/go.mod

core/services/workflows/v2/utils.go

cl-sonarqube-production · 2026-04-02T21:22:30Z

Quality Gate passed

Issues
1 New issue
9 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

vault: link org ids via org resolver

2ebdfcc

prashantkumar1982 requested review from a team as code owners March 26, 2026 06:47

product-security-plaid-production bot requested a review from silaslenihan March 26, 2026 06:48

product-security-plaid-production bot requested review from george-dorin and pavel-raykov March 26, 2026 06:48

vault: verify workflow owner org linkage

20975e0

prashantkumar1982 added 5 commits March 26, 2026 00:17

vault: log org identity linking decisions

1324232

vault: use get secrets identity fields

14686fe

vault: resolve get secrets identity from metadata

245765f

vault: clean up linker lint issues

ba86d78

chore: run gomodtidy

df9855b

prashantkumar1982 requested a review from a team as a code owner March 26, 2026 08:08

product-security-plaid-production bot requested a review from Tofel March 26, 2026 08:08

vault: gate linker behind org id owner flag

4471626

prashantkumar1982 changed the title ~~vault: link org ids via org resolver~~ vault: integrate linking service identity resolution Mar 26, 2026

prashantkumar1982 added 3 commits March 26, 2026 01:34

vault: tighten get secrets owner checks

87149f8

vault: fail closed without request identity linker

cb66432

Merge origin/develop into codex/pr8-orgresolver-linking

e39d90a

ibrajer reviewed Mar 27, 2026

View reviewed changes

Merge origin/develop into codex/pr8-orgresolver-linking

0836fc5

prashantkumar1982 added 9 commits April 1, 2026 12:32

Merge origin/develop into codex/pr8-orgresolver-linking

b63e1f4

apply gomodtidy updates

27dbf5c

gate workflow org id forwarding and simplify vault execute

0707b8d

simplify vault execute and clean workflow lint

13cca13

fix workflow v2 secrets integration test

742bab2

fix workflow org resolver test setup

f1dff84

simplify workflow org resolution lifecycle

6aacb5b

gate workflow org identity propagation

bdb356b

fix workflow v2 gate-aware tests

e7648a5

cedric-cordenier reviewed Apr 2, 2026

View reviewed changes

core/services/workflows/v2/capability_executor.go Outdated Show resolved Hide resolved

cedric-cordenier reviewed Apr 2, 2026

View reviewed changes

core/services/workflows/v2/engine.go Show resolved Hide resolved

cedric-cordenier reviewed Apr 2, 2026

View reviewed changes

refine vault linking and workflow org gating

29d8d0d

ibrajer previously approved these changes Apr 2, 2026

View reviewed changes

jmank88 reviewed Apr 2, 2026

View reviewed changes

core/scripts/go.mod Show resolved Hide resolved

jmank88 reviewed Apr 2, 2026

View reviewed changes

core/scripts/cre/environment/examples/workflows/v1/proof-of-reserve/cron-based/go.mod Outdated Show resolved Hide resolved

jmank88 reviewed Apr 2, 2026

View reviewed changes

core/services/workflows/v2/utils.go Outdated Show resolved Hide resolved

Address workflow review comments

e0cf48d

prashantkumar1982 dismissed ibrajer’s stale review via e0cf48d April 2, 2026 20:51

jmank88 approved these changes Apr 2, 2026

View reviewed changes

vreff approved these changes Apr 2, 2026

View reviewed changes

prashantkumar1982 added this pull request to the merge queue Apr 2, 2026

Merged via the queue into develop with commit 980066b Apr 2, 2026
232 of 234 checks passed

prashantkumar1982 deleted the codex/pr8-orgresolver-linking branch April 2, 2026 21:42

		@@ -66,15 +70,18 @@ func NewSecretsFetcher(
		lggr = logger.Named(lggr, "WorkflowEngine.SecretsFetcher")
		lggr = logger.With(lggr, "workflowID", workflowID, "workflowName", workflowName, "workflowOwner", workflowOwner, "phaseID", phaseID)

Conversation

prashantkumar1982 commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

github-actions bot commented Mar 26, 2026

Uh oh!

github-actions bot commented Mar 26, 2026

Uh oh!

github-actions bot commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trunk-io bot commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CORA - Pending Reviewers

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cl-sonarqube-production bot commented Apr 2, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

prashantkumar1982 commented Mar 26, 2026 •

edited

Loading

github-actions bot commented Mar 26, 2026 •

edited

Loading

trunk-io bot commented Mar 26, 2026 •

edited

Loading

github-actions bot commented Mar 26, 2026 •

edited

Loading