vault: integrate linking service identity resolution#21715
vault: integrate linking service identity resolution#21715prashantkumar1982 wants to merge 11 commits intodevelopfrom
Conversation
|
👋 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! |
|
I see you updated files related to
|
|
✅ No conflicts with other open PRs targeting |
CORA - Pending Reviewers
Legend: ✅ Approved | ❌ Changes Requested | 💬 Commented | 🚫 Dismissed | ⏳ Pending | ❓ Unknown For more details, see the full review summary. |
|
| 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 != "": |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
| if workflowOwner == "" { | ||
| return LinkedVaultRequestIdentity{OrgID: orgID, WorkflowOwner: workflowOwner}, nil | ||
| } |
There was a problem hiding this comment.
This can probably be extracted as an independent condition about this if statement, because it will be checked again on L95.




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
org_idandworkflow_owner, returns trusted values, or failsorg_idfromworkflow_ownerthrough the linking service when neededworkflow_owner -> org_idmappings when both fields are present, and reject mismatchesGetSecretsso forwarded plugin requests carry the resolved identity fieldsOrgResolverpath for linking-service calls, including its existing node-JWT-authenticated request flow