-
Notifications
You must be signed in to change notification settings - Fork 136
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
docs: Add example for using GCP Workload Identity #2000
base: main
Are you sure you want to change the base?
docs: Add example for using GCP Workload Identity #2000
Conversation
This closes slsa-framework#1732. Signed-off-by: Chasen Bettinger <[email protected]>
@ianlewis Would love your feedback! |
Signed-off-by: Chasen Bettinger <[email protected]>
Signed-off-by: Chasen Bettinger <[email protected]>
|
||
``` | ||
|
||
NOTE: There are existing challenges with using secrets in reusable workflows. Due to these problems, you will likely need to use unencrypted environment variables. To learn more: https://github.com/orgs/community/discussions/17554 and https://colinsalmcorner.com/consuming-environment-secrets-in-reusable-workflows/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm misunderstanding something but IIUC, Since the user isn't writing a reusable workflow, but rather calling one, this shouldn't really be an issue. Are you referring to something specific here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was my attempt at articulating that the caller cannot pass values within the secrets.
object into reusable workflows. They'll have to use whatever is stored in vars.
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is specific to our reusable workflows or to workload identity so maybe we can just leave this out as I think it might confuse the reader.
Or maybe you can be more specific? Like saying something like "WORKLOAD_IDENTITY_PROVIDER
and SERVICE_ACCOUNT
should be stored in vars
rather than secrets
as you cannot pass secrets to reusable workflow inputs".
wdut?
BTW thanks for writing this up! Overall it looks great! |
Signed-off-by: Chasen Bettinger <[email protected]>
@ianlewis Ready for re-review. Thanks for feedback 😄 |
# EXAMPLE: | ||
# northamerica-northeast1-docker.pkg.dev/blank-check-231234/your-repository | ||
REPOSITORY_PATH: ${{ vars.REPOSITORY_PATH }} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please set the default pemissions, e.g.
permissions: read-all
or
permissions:
contents: read
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the what or why behind this comment. Could you expand please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that if this is meant to be a full example it should include a set of default permissions.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
The defaults are usually permissive and we'd like to encourage folks to explicitly set them to be less permissive.
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
Signed-off-by: Chasen Bettinger <[email protected]>
As mentioned in the README there are issues with
passing encrypted secrets into reusable workflows.
There aren't valid workarounds at the moment, so
I believe users are forced to use generic environment
variables.
This closes #1732.