[infra/deploy] ci: Harden GitHub Actions

[step-security-bot]

Summary

I'm onboarding our new CI/CD security tool: HardenRunner. A few lines are added to certain workflow files to enable the scanners.

It will scan for anomalies on the CI/CD side without making any changes (unless manually requested).

part of https://github.com/neondatabase/cloud/issues/21253

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[jcgruenhage]

The changes here can be split in a few different categories:

1. "Harden Runner" which sets up network egress monitoring
2. pinning sha hashes for container images and actions
3. setting the default permission to contents: read
4. add a dependabot config
5. add a pre-commit config
6. add a scorecards workflow
7. add a codeql workflow
8. add a dependency review workflow

I think 1 and 2 are good and should be merged. 3 is questionable, as you can set that globally, as documented in https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token. 4 sounds good as well. 5 is a bit complicated, as we now have pre-commit hooks defined in multiple places, which we should unify, and the chosen hooks are a weird selection, that don't really fit the work happening in this repo. 6 and 7 I'm not sure about, I don't know these and don't know what value they provide. 8 is a bit complicated: We already check dependencies with cargo-deny, and I haven't found what languages this new action supports from a quick glance at the readme.

[jcgruenhage]

Do we need to duplicate this in every workflow file? If restricting the default permissions is something we want to do, then github has an enterprise level default permission that we can set to restricted: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

[areyou1or0]

hmm, but it wouldn't work in certain occasions like the following comment you dropped which requires write permissions. Not sure if it'd break stuff.

[jcgruenhage]

In those cases we can still be more permissive with the permissions field in the workflow. If we want to default to read only permissions (which is good IMO), I'd prefer if we did that in a global setting instead of replicating this snippet everywhere.

[jcgruenhage]

I'm still unsure about the permissions thing. I'd really prefer setting that globally and only overwriting the default in the workflow file where it's necessary to get more permissions, like with the workflow for creating release PRs.

My opinion on this is not strong enough to click "request changes" again, but it's not an approval either. Can someone else also weigh in on this?

[areyou1or0]

I don't have a strong opinion on this, open to hear what the rest of the team thinks.

If agreed upon, I can change the files accordingly, just let me know.

[jcgruenhage]

I've discussed this with @fedordikarev, and the result was to go with it as is to not slow things down, and maybe revisit the global setting in the future. When we merge this, we need to announce it so that people are aware of this, because I'm fairly certain a few workflows will break due to permission, and not all of them will be caught before the merge. The devprod oncall can handle fixing permissions where they arise though, so that should be fine, as long as people know to reach out to us.

I think we can merge this as soon as CI passes - if that's today I'd announce it in the platform sync so that people know about it.

[fedordikarev]

yeah, still waiting for answers in Slack, to have final agreement.
meanwhile, lets check that CI will be also happy and follow on any issues found

[areyou1or0]

Thank you both, as I told @fedordikarev I'm totally flexible, I don't wanna cause issues. We can merge it as it is, if it causes issues, we can remove certain scans or look for an alternative implementation.

[jcgruenhage]

Approving so that CI can run

[fedordikarev]

with all the discussions and caveats, lets approve and check CI run
it should work and will take a closer look after merged