Skip to content
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

Closed
thepwagner opened this issue Jul 26, 2023 · 3 comments
Closed

Managing the allowed actions list #444

thepwagner opened this issue Jul 26, 2023 · 3 comments

Comments

@thepwagner
Copy link

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?

@spencerschrock
Copy link
Member

spencerschrock commented Jul 26, 2023

I prefer this approach to longer-lived and wider scoped Personal Access Tokens

Regarding wide scope, have you experimented with fine-grained tokens?

https://github.com/ossf/scorecard-action/blob/b45bfe698803b7f0a672c4d3e020bfbc89a5e66d/README.md#authentication-with-fine-grained-pat-optional

Running the action in the scorecard job is blocked by the allowlist

Note: this restriction is only true when publishing results

@thepwagner
Copy link
Author

thepwagner commented Jul 26, 2023

Regarding wide scope, have you experimented with fine-grained tokens?

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:

  • I can generate 1 token per repository, and store as a repository-level Actions secret. This is a management pain; it could be automated using a system like https://github.com/thepwagner/secret-garden .
  • I can generate 1 token with organization-level access and store as an organization-level Actions secret. This is tolerable to manage, but gives every workflow access to every repository.

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"}
}

@thepwagner
Copy link
Author

thepwagner commented Aug 4, 2023

Is there any process for discussing the allowed actions list?

Closing as this is answered to me: it's case-by-case so open an issue/PR for discussion.

Thanks!

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

No branches or pull requests

2 participants