Draft
Conversation
Contributor
|
New Issues (3)Checkmarx found the following issues in this Pull Request
Fixed Issues (1)Great job! The following issues were fixed in this Pull Request
|
This was referenced Mar 17, 2026
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
Prototype for adding a Manage permission to Secrets Manager access policies, enabling a dedicated tier for administering who can access projects and secrets separate from Read/Write data access.
client-demo.mp4
Prototype explanation
This prototype introduces a new can manage permission fo Secrets Manager
Manage without Write, or Write without Read, is not possible — enforced by database constraints.
What manage enables
Manage exclusively governs who can view and modify access policies on a resource. It does not affect what the holder can do to the resource itself, that remains governed by Write.
On a Project
On a Secret
On a Machine Account
Restrictions on Machine Accounts
Granting Manage
Users with Manage can freely grant or adjust Manage on any resource they control. Machine accounts face additional restrictions:
Projects — Only the machine account that created the project can grant Manage to others on that project. A machine account given Manage (but not the creator) can use the permission but cannot grant it to anyone else. Additionally, the creator can only grant Manage to itself on machine account access policies — not to other machine accounts.
Rationale: prevents a machine account from using a granted Manage permission to further delegate control it was never intended to have. Manage delegation is anchored to the machine account that established the project, keeping the privilege chain auditable and explicit.
Secrets — Secrets have no creator of their own. The system uses the creator of the secret's parent project and applies the same rule.
Hard Limits
Machine accounts cannot modify people access policies on other machine accounts under any circumstances.
Rationale: if a machine account were compromised, it should not be able to grant human users access to other machine accounts, which could then be used to pivot further. Keeping humans in control of human-to-machine-account access ensures a person is always in the authorization chain.
Machine accounts cannot call the secret access policy write endpoint — only users can modify secret-level access policies.
Rationale: secret access policies determine who can read sensitive values. Restricting writes to human callers ensures that a compromised machine account cannot silently expand its own access or the access of other machine accounts to secrets.
Lockout protection
If a project has at least one person (user or group) with Manage, replacing the people policies in a way that removes all human Manage grants is blocked with a
400 Bad Request. This ensures a human can always recover control of the project.Existing permissions after migration
Write = true→ backfilled toManage = trueManage = falseregardless of Write valueExisting human administrators keep their ability to manage access policies. Machine accounts must be explicitly granted Manage by a user or the creator machine account.
Access policy event logs
Events are emitted whenever access policies are created, removed, or have their permissions changed. No event is emitted for a no-op (e.g. replacing a policy with identical Read/Write/Manage values).
Secret access events
Fired when a secret's access policies are modified via
PUT /secrets/{secretId}/access-policies.Secret_UserAccessGrantedSecret_UserAccessRevokedSecret_UserAccessUpdatedSecret_GroupAccessGrantedSecret_GroupAccessRevokedSecret_GroupAccessUpdatedSecret_ServiceAccountAccessGrantedSecret_ServiceAccountAccessRevokedSecret_ServiceAccountAccessUpdatedProject access events
Fired when a project's people or machine account access policies are modified. These events are also emitted when changes are made from the machine account side (granted policies) — the same event types are used in both cases.
Project_UserAccessGrantedProject_UserAccessRevokedProject_UserAccessUpdatedProject_GroupAccessGrantedProject_GroupAccessRevokedProject_GroupAccessUpdatedProject_ServiceAccountAccessGrantedProject_ServiceAccountAccessRevokedProject_ServiceAccountAccessUpdatedMachine account access events
Fired when a machine account's people access policies are modified via
PUT /service-accounts/{id}/access-policies/people.The
Added/Removedevents below pre-date this feature. ThePermissionUpdatedevents (2306–2307) are new and fire only when an existing policy's permissions change — they do not fire when a policy is added or removed.ServiceAccount_UserAddedServiceAccount_UserRemovedServiceAccount_UserPermissionUpdatedServiceAccount_GroupAddedServiceAccount_GroupRemovedServiceAccount_GroupPermissionUpdatedRelated Draft PRs
This prototype is depending on the following draft PRs: