Skip to content

Vault refactor to support workflowOwner as owner of a secret#2068

Merged
prashantkumar1982 merged 9 commits into
mainfrom
vault-owner-refactor-common
May 20, 2026
Merged

Vault refactor to support workflowOwner as owner of a secret#2068
prashantkumar1982 merged 9 commits into
mainfrom
vault-owner-refactor-common

Conversation

@prashantkumar1982
Copy link
Copy Markdown
Contributor

@prashantkumar1982 prashantkumar1982 commented May 18, 2026

Supports smartcontractkit/chainlink#22525.

Design: Vault DON design doc (new) — JWT Vault tenants and related behavior.

Tenant for the Vault JWT path is configured in Chainlink job specs (auth0.tenantID, alongside issuer and audience; see chainlink#22525). This chainlink-common change keeps cresettings aligned with that model.

Coordination

  • Land alongside Go module bumps on chainlink#22525 pinned to the chainlink-common revision that contains this change.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 18, 2026

✅ API Diff Results - github.com/smartcontractkit/chainlink-common

✅ Compatible Changes (1)

pkg/settings/cresettings.Schema (1)
  • PropagateOrgIDInRequestMetadata — ➕ Added

📄 View full apidiff report

@prashantkumar1982 prashantkumar1982 marked this pull request as ready for review May 19, 2026 05:34
@prashantkumar1982 prashantkumar1982 requested a review from a team as a code owner May 19, 2026 05:34
Comment on lines +41 to +42
reserved 2, 3;
reserved "org_id", "workflow_owner";
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Did you consider this method of deprecation?

Suggested change
reserved 2, 3;
reserved "org_id", "workflow_owner";
string org_id = 2 [deprecated = true];
string workflow_owner = 3 [deprecated = true];

The advantage being that the generated code will remain compatible.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I actually revisited this, and decided to delete entirely.
These fields were never used on prod or even staging. They are not not needed as per design changes. So best is to just delete them, as we know it is safe

Copy link
Copy Markdown
Contributor

@jmank88 jmank88 May 19, 2026

Choose a reason for hiding this comment

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

These fields are currently referenced from chainlink/v2 though. Please do not remove them in a breaking manner.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Removed them all here: smartcontractkit/chainlink#22525

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That's great but the historical references are still there, so the incompatibility may still come up, e.g. when backporting to a release patch, or when working in chainlink-deployments or a chain integrations-tests/ module.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ok, these fields were just added recently and never used/shipped so the only risk is when someone is backporting to an older release branch.
So bringing the fields back with deprecated tag.

Comment thread pkg/settings/cresettings/settings.go Outdated
Comment thread pkg/settings/cresettings/settings.go Outdated
Comment thread pkg/capabilities/capabilities.go
@prashantkumar1982 prashantkumar1982 requested a review from jmank88 May 19, 2026 18:32
Comment thread pkg/capabilities/capabilities.go Outdated
@prashantkumar1982 prashantkumar1982 requested a review from jmank88 May 20, 2026 16:01
russell-stern
russell-stern previously approved these changes May 20, 2026
Comment thread pkg/settings/cresettings/settings.go Outdated
VaultOrgIdAsSecretOwnerEnabled Setting[bool]
VaultOrgIdAsSecretOwnerEnabled Setting[bool] // Deprecated
PropagateOrgIDInRequestMetadata Setting[bool]
TenantID Setting[uint64]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there any more we could add to this name? Because it may be confused with the settings package notion of tenant. I notice you already removed the Vault prefix.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

removed this, and added to job-specs

@prashantkumar1982 prashantkumar1982 added this pull request to the merge queue May 20, 2026
Merged via the queue into main with commit 11a4f36 May 20, 2026
33 checks passed
@prashantkumar1982 prashantkumar1982 deleted the vault-owner-refactor-common branch May 20, 2026 19:57
GatewayIncomingPayloadSizeLimit: Size(1 * config.MByte),
GatewayVaultManagementEnabled: Bool(true),
VaultJWTAuthEnabled: Bool(false),
// Deprecated: retained for backwards compatibility; workflow owner identifies secret ownership.
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

One thing to note here is that we never shipped a CLI version that used org owned secrets so we do not need to maintain backwards compatibility. This can be safely deprecated

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Thanks, yes agreed.
I initially deleted it, but @jmank88 asked to keep it deprecated.

I think it is just an artifact of this field existing in cld repo on some env, or if an older release branch needs to bump chainlink-common.

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.

4 participants