-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Managing the allowed actions list #444
Comments
Regarding wide scope, have you experimented with fine-grained tokens?
Note: this restriction is only true when publishing results |
Yep! This is the solution I'm currently forced into. In my case I've got hundreds of repositories I'd like to be publishing scorecards for. Using fine-grained PATs I see two paths:
My solution let's me write a single policy that allows any workflow to get a token with these exact permissions, only when executing a trusted shared/reusable workflow, from a public repository I own, while requesting permission to itself and only itself. The GitHub token is issued as the workflow runs, and revoked immediately after the workflow completes. allow {
input.claims.iss == "https://token.actions.githubusercontent.com"
input.claims.job_workflow_ref == "thepwagner-org/actions/.github/workflows/scorecard.yaml@refs/heads/main"
input.claims.repository_visibility == "public"
input.claims.repository_owner == "thepwagner-org"
input.repositories = [input.claims.repository]
input.permissions == { "administration":"read", "metadata":"read", "repository_hooks":"read"}
} |
Closing as this is answered to me: it's case-by-case so open an issue/PR for discussion. Thanks! |
Is there any process for discussing the allowed actions list?
Should contributors just open PRs like #204 , what criteria will be considered?
My desired exception is https://github.com/thepwagner/token-action . This action uses the OIDC token to exchange for a GitHub token, which I intended to use to provide
administration:read
permissions. I prefer this approach to longer-lived and wider scoped Personal Access Tokens.Running the action in the scorecard job is blocked by the allowlist, and running in a preceding job is blocked by the
id-token: write
filtering. Proof-of-concept here.I assume this use case doesn't justify an exception, what would?
The text was updated successfully, but these errors were encountered: