-
Notifications
You must be signed in to change notification settings - Fork 33
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
Reducing security risk in our GitHub workflows #404
Comments
More information in the github docs but there's also a degree of trust that informs how to do each pin:
The downside of 1. is that we need to update actions often, and especially means we won't get security updates if we don't stay on top of it (dependabot helps, I think?). So there can actually be a downside security-wise of pinning if it's the action itself that has a vulnerability (e.g. the codecov action contents had the vulnerability, the action repo itself was not compromised). For instance, I think it would be reasonable to trust |
@minrk good points, then I suggest we trust |
dockerspawner, jupyter-remote-desktop-proxy, jupyter-server-proxy, jupyterhub-idle-culler: pypa/gh-action-pypi-publish@v1.4.1 / @v1.3.0 (latest is 1.4.2) Feels okay for me to trust even though I would prefer we just do the terminal command ourselves directly to upload a package. Perhaps use Suggestion: we retain use of the pypa action, we trust it, and reference |
@sgibson91 @betatim @minrk what do you think about use of the following actions in mybinder.org-deploy's CD workflow jobs?
|
Yeah, I think that's okay. It doesn't do much, so we could also do our own |
In https://github.com/jupyterhub/sudospawner/pull/69/files#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34R23-R36 I've added a suggestion on the equivalent of using the PyPA action. It is pretty much to run: |
I don't think we should track this further than we have done by making the default permission for GITHUB_TOKEN that actions can access be |
I've created this issue to coordinate security work across the org.
As initiated by @manics practically in jupyterhub/action-major-minor-tag-calculator#75 and by the discussion in #398 (comment), we should do various things for our GitHub repos' GitHub workflows to improve the security posture against compromised GitHub actions.
Action points for each repo
In all GitHub workflows' jobs that are referencing a GitHub secret such as
secrets.GITHUB_TOKEN
or a manually configured such assecrets.DOCKERHUB_TOKEN
, we should:Consider what actions we use and if we trust them
Pin the action references to a specific git commit hashes and make an inline comment
# associated tag: v1.2.3
for easier maintainabilityIf needed, we should add write permissions explicitly for the
secrets.GITHUB_TOKEN
which previously had them by default but doesn't any more as we made them read-only by default in the JupyterHub github org. This will be needed for jobs that update branches or tags in the repo for example.Non-archived repositories to consider
Has GHA in use
Hasn't started using GHA for documentation publishing.
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Missing credentials to push to PyPI (Provide permissions to upload releases to PyPI for use in our CI system nativeauthenticator#144)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
I think there is work that needs to be done here with regards to being explicit about the need for GITHUB_TOKEN's permissions. I created Explicit permissions for GITHUB_TOKEN repo2docker-action#64 to represent this.
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
No publish workflow setup: No publish to PyPI workflow setup sudospawner#68
Discussed: Reducing security risk in our GitHub workflows #404 (comment)
Doesn't have GHA in use, but have a need for tests/GHA
Doesn't have GHA in use, and have no need for it
Script to list repos of relevance
I used this script to get the names of repo's of relevance to create the lists above.
The text was updated successfully, but these errors were encountered: