feat: add VaultJWTAuthEnabled and VaultOrgIdAsSecretOwnerEnabled feature gates and vault proto fields for JWT auth#1921
Conversation
prashantkumar1982
temporarily deployed
to
integration
GitHub Actions
Inactive
prashantkumar1982
had a problem deploying
to
integration
GitHub Actions
Error
prashantkumar1982
had a problem deploying
to
integration
GitHub Actions
Error
✅ API Diff Results -
|
… JWT auth Add org_id and workflow_owner fields to CreateSecretsRequest, UpdateSecretsRequest, DeleteSecretsRequest, and ListSecretIdentifiersRequest proto messages. Add VaultJWTAuthEnabled boolean setting (default: false) to cresettings. No behavior change — new proto fields default to empty strings and the gate is off. Made-with: Cursor
prashantkumar1982
force-pushed
the
feat/vault-jwt-auth-gate-proto
branch
from
73e1c21 to
7ffd1b3
Compare
prashantkumar1982
temporarily deployed
to
integration
GitHub Actions
Inactive
prashantkumar1982
temporarily deployed
to
integration
GitHub Actions
Inactive
prashantkumar1982
had a problem deploying
to
integration
GitHub Actions
Failure
…ate-proto Made-with: Cursor
prashantkumar1982
temporarily deployed
to
integration
GitHub Actions
Inactive
prashantkumar1982
had a problem deploying
to
integration
GitHub Actions
Failure
prashantkumar1982
temporarily deployed
to
integration
GitHub Actions
Inactive
Add VaultOrgIdAsSecretOwnerEnabled boolean setting (default: false) to cresettings, gating the upcoming org-id-as-secret-owner behavior for Vault requests. No behavior change — the gate defaults to off. Updated golden files (defaults.json, defaults.toml), README flowchart, and test assertions. Made-with: Cursor
prashantkumar1982
had a problem deploying
to
integration
GitHub Actions
Failure
prashantkumar1982
temporarily deployed
to
integration
GitHub Actions
Inactive
prashantkumar1982
had a problem deploying
to
integration
GitHub Actions
Failure
prashantkumar1982
changed the title
| string request_id = 1; | ||
| repeated EncryptedSecret encrypted_secrets = 2; | ||
| string org_id = 3; | ||
| string workflow_owner = 4; |
There was a problem hiding this comment.
Hmmmmm -- I'm not following: why do we need the org_id and workflow_owner here? Shouldn't it live on the SecretIdentifier message?
There was a problem hiding this comment.
We need both till we are in migration phase.
Where would you put them instead?
Inside each SecretIdentifier item as additional field?
We could do that, but seems less elegant.
Also, I am thinking, after the migration, we should move owner field to outside of Identifier.
It is more of a request level attribute than per-secret attribute.
There was a problem hiding this comment.
What happens once we introduce policies over secrets though? I think it's useful to distinguish between the owner making the request and the owner of the secret.
Are we expecting that the CLI will provide both values? Also one thing to bear in mind is that these messages are used across multiple layers (plugin, gateway -> node, user -> gateway); maybe this is an opportunity to start separating between what we expect the user to provide and what we add on the way
There was a problem hiding this comment.
When we introduce policies, I assume more things will change. Like sub-owners, roles.
But even in that model, orgId will still be an overall customer level field, not per secret field.
In any case, I don't want to think about forward compatibility with policies support, since that will be a bigger change anyways.
The workflow_owner we will likely get rid of here in future.
maybe this is an opportunity to start separating between what we expect the user to provide and what we add on the way
Yes, this sounds like a good refactor to do. Basically split the protos/messages we pass between each layer. But that will be more disruptive, and I would like to do it separately in a different set of PRs.
At this point, we need a way to pass trusted orgId and workflowOwner from Vault Gateway handler to the Capability/Plugin.
What do you think? I am open to doing this refactor now too, as a pre-req before other changes. But will likely act on it immediately as it blocks all other work.
There was a problem hiding this comment.
Are we expecting that the CLI will provide both values?
No, the CLI will provide different things:
- Allowlist based auth: CLI provides verified workflowOwner only.
- jwt based auth: CLI provides orgID, and optionally an untrusted workflowOwner
Our Vault Cap node will derive both OrgID and WorkflowOwner in a trusted manner, and then pass them to the plugin.
2 participants
Summary
VaultJWTAuthEnabledboolean setting (default:false) tocresettings, gating the upcoming JWT-based authorization flow for Vault requests.VaultOrgIdAsSecretOwnerEnabledboolean setting (default:false) tocresettings, gating the use oforg_idas the secret owner for Vault instead ofworkflow_owner.org_idandworkflow_ownerfields to four vault proto request messages:CreateSecretsRequest,UpdateSecretsRequest,DeleteSecretsRequest, andListSecretIdentifiersRequest.defaults.json,defaults.toml), README flowchart, and test assertions.No behavior change — new proto fields default to empty strings, and both feature gates default to
false.This is PR 1 of the Vault JWT Auth rollout plan. All subsequent PRs depend on the gate settings and/or proto fields introduced here.