Skip to content

vault: integrate linking service identity resolution#21715

Open
prashantkumar1982 wants to merge 11 commits intodevelopfrom
codex/pr8-orgresolver-linking
Open

vault: integrate linking service identity resolution#21715
prashantkumar1982 wants to merge 11 commits intodevelopfrom
codex/pr8-orgresolver-linking

Conversation

@prashantkumar1982
Copy link
Contributor

@prashantkumar1982 prashantkumar1982 commented Mar 26, 2026

Summary

This integrates the Vault capability with the linking service so requests can resolve and verify org identity before they are forwarded to the vault OCR plugin.

The behavior remains gated by VaultOrgIdAsSecretOwnerEnabled.
When that limiter is disabled, the linker is a no-op and request identity fields pass through unchanged.

What Changed

  • add a dedicated Vault linker layer that takes org_id and workflow_owner, returns trusted values, or fails
  • resolve org_id from workflow_owner through the linking service when needed
  • verify workflow_owner -> org_id mappings when both fields are present, and reject mismatches
  • wire the linker into Vault CRUD requests and GetSecrets so forwarded plugin requests carry the resolved identity fields
  • use the shared OrgResolver path for linking-service calls, including its existing node-JWT-authenticated request flow
  • add targeted logging around identity resolution and failure paths

@github-actions
Copy link
Contributor

👋 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
Copy link
Contributor

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
Copy link
Contributor

github-actions bot commented Mar 26, 2026

✅ No conflicts with other open PRs targeting develop

@trunk-io
Copy link

trunk-io bot commented Mar 26, 2026

Static BadgeStatic BadgeStatic BadgeStatic Badge

View Full Report ↗︎Docs

@prashantkumar1982 prashantkumar1982 requested a review from a team as a code owner March 26, 2026 08:08
@github-actions
Copy link
Contributor

github-actions bot commented Mar 26, 2026

CORA - Pending Reviewers

Codeowners Entry Overall Num Files Owners
* 1 @smartcontractkit/foundations, @smartcontractkit/core
/core/capabilities/ 4 @smartcontractkit/keystone, @smartcontractkit/capabilities-team
/core/services/ocr* 1 @smartcontractkit/foundations, @smartcontractkit/core
go.mod 6 @smartcontractkit/core, @smartcontractkit/foundations
go.sum 6 @smartcontractkit/core, @smartcontractkit/foundations
integration-tests/go.mod 1 @smartcontractkit/core, @smartcontractkit/devex-tooling, @smartcontractkit/foundations
integration-tests/go.sum 1 @smartcontractkit/core, @smartcontractkit/devex-tooling, @smartcontractkit/foundations

Legend: ✅ Approved | ❌ Changes Requested | 💬 Commented | 🚫 Dismissed | ⏳ Pending | ❓ Unknown

For more details, see the full review summary.

@prashantkumar1982 prashantkumar1982 changed the title vault: link org ids via org resolver vault: integrate linking service identity resolution Mar 26, 2026
@cl-sonarqube-production
Copy link

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 != "":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +69 to +71
if workflowOwner == "" {
return LinkedVaultRequestIdentity{OrgID: orgID, WorkflowOwner: workflowOwner}, nil
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants