Feature: add argument --ghe-hostname for GHE Servers

[runjivu]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through the open issues for a duplicate request.

What's the problem this feature will solve?

I'm trying zizmor out with GHE Server repos, but for now github_api client's api_base is fixed to "https://api.github.com".

Describe the solution you'd like

by adding additional parameter --ghe-hostname, i can run something like
zizmor --gh-token {token} --ghe-hostname {github.example.com} example/repos,
which would be nice

Additional context

I am new to GitHub Actions security hardening.
In a GHE Server / self-hosted runner environments, it seems/feels inherently safer against many attacks..
Are they really?
I’d love to hear some advice on what specific things I should focus on to keep things secure in these environments! 😃

[woodruffw]

Hi @runjivu, thanks for the feature request!

Overall, this sounds like a good idea to me -- supporting both hosted and on-prem GHE is something we should do.

A couple of thoughts:

1. How does this interact across multiple instances/hosts? For example, if a repo on a GHE host references actions/checkout, how do we ensure that the user's GH_TOKEN works for both the GHE host and the normal GH host, e.g. for the impostor-commit audit?
2. How does GitHub's own gh CLI handle these cases? IMO we should closely mirror their own flags/behavior here.

In a GHE Server / self-hosted runner environments, it seems/feels inherently safer against many attacks..
Are they really?

It depends 🙂: self-hosted runners come in a large variety of configurations, some of which are less secure than GitHub-hosted runners. In general, GitHub recommends only using self-hosted runners on private repos, regardless of whether the repo is on a GH or GHE host.

In general however, my understanding is that the "best practice" for self-hosted runners is to never use persistent runners (only use ephemeral runners), and to manage your runners at whatever organizational level makes sense for your use case (e.g. repo/org/enterprise level) and not allow deviations from that level.

Some more docs here: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security

[runjivu]

Hi @woodruffw , thank you for the quick response!

my initial thoughts on your points :

1. How does GitHub's own gh CLI handle these cases?

when logging in with gh auth login,
gh cli seems to store and use hostnames under ~/.config/gh/hosts.yml , and set corresponding tokens to keychain.
example :

github.com:
    git_protocol: https
    users:
        runjivu:
    user: runjivu
github.example.com:
    git_protocol: https
    users:
        haneul:
    user: haneul

so as long as zizmor intends to get token directly with --gh-token , i think just passing --ghe-hostname may be sufficient enough ( fyi the flag for gh auth login is --hostname )

2. How does this interact across multiple instances/hosts?

As far as I know, forks between github instances are prohibited, as github not does not provide a direct way to fork between separate instances . (I might be wrong, but i couldn't find related docs 😢)

According to reference doc, actions for GHE server first looks for repos in GHE instance, and then for actions in github.com.
(only if github connect is turned on)

reference : https://docs.github.com/en/enterprise-server@3.11/admin/managing-github-actions-for-your-enterprise/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect#about-resolution-for-actions-using-github-connect

Since my organization does not enable github connect,
gh_token for GHE server was sufficient enough to do impostor-commit.

But for broader coverage impostor_commit.rs should also check for public actions for github.com also!

Lastly thank you for the advice, I'll start from there! and thanks for building this project!
It's great to be able to scan for workflow security holistlicly with zizmor 😀

[woodruffw]

i think just passing --ghe-hostname may be sufficient enough ( fyi the flag for gh auth login is --hostname )

Thanks, makes sense!

To bikeshed a bit: how do you feel about making it --gh-hostname? IMO that would be more consistent with the existing --gh-token flag. We could also allow GH_HOST to override it in the environment, which would be consistent with gh.

According to reference doc, actions for GHE server first looks for repos in GHE instance, and then for actions in github.com.

TIL, thanks for finding that!

[runjivu]

Yes that makes sense, will do!
Should i work on PR #363 ?

[woodruffw]

Yes that makes sense, will do! Should i work on PR #363 ?

Yes, thanks!

[woodruffw]

Completed with #363 and #371.