You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In large orgs, if someone were able to commit a file with an undesired org, this undesired org has access to a private org.
As a octo-sts implementor,
I want to restrict the orgs that can obtain tokens in octo-sts
So that I can be assured no unauthorized org can ever gain access using octo-sts
Potential Solution
Envisioning a way to instruct Octo-STS to only hand out tokens to valid declared orgs in a policy.
In the STS policies there's already the subject_pattern being used. I am proposing to use the org bounded claim instead of repo if possible for this.
The policy definition would live at the org level under something like .github/.chainguard/policy.sts.yaml.
Policy Definitions for STS Policies
Outcome - Deny undesired cross-org access
@wlynch mentioned possibly incorporating into -> https://github.com/octo-sts/app/blob/main/pkg/webhook/webhook.go
Problem
In large orgs, if someone were able to commit a file with an undesired org, this undesired org has access to a private org.
As a octo-sts implementor,
I want to restrict the orgs that can obtain tokens in octo-sts
So that I can be assured no unauthorized org can ever gain access using octo-sts
Potential Solution
Envisioning a way to instruct Octo-STS to only hand out tokens to valid declared orgs in a policy.
In the STS policies there's already the
subject_pattern
being used. I am proposing to use the org bounded claim instead of repo if possible for this.The policy definition would live at the org level under something like
.github/.chainguard/policy.sts.yaml
.figured maybe we'd need a
kind
to be added?The text was updated successfully, but these errors were encountered: