chore: Fixing non-propagated custom GH token in forked PRs

[heyvister1]

Since custom GH secrets are not propagated for forked repos, we need a way to have GH token to generate docs repo PRs under network-operator repo.
Solution:

• Use fine grained Github Personal Access Token (PAT), for nvidia-ci-cd user , with limited network-operator-docs permissions

• There is a need to add GH_DOCS_TOKEN PAT token for nvidia-ci-cd user

[killianmuldoon]

What happens if some one creates a PR to this action with a script to exfiltrate the token before the check runs?

[heyvister1]

What happens if some one creates a PR to this action with a script to exfiltrate the token before the check runs?

He needs to gain GH_TOKEN first, but he should be blocked on the first step which checks his membership

[maze88]

Does the GH API return an appropriate status code (404?) if the actor is not part of the organization?
If so, this could be shortened to if curl -f ... ; then?

[killianmuldoon]

He needs to gain GH_TOKEN first, but he should be blocked on the first step which checks his membership

What if I create an MR which changes that first step?

[heyvister1]

He needs to gain GH_TOKEN first, but he should be blocked on the first step which checks his membership

What if I create an MR which changes that first step?

So this is not only related to my PR change, if anyone can create its own workflow file which will be engaged in PR then we're in a bad shape.
For current status, docs repo can be triggered manually by maintainers. So non-privileged collaborators cannot engage it.
The following workflow is triggered by network-operator PRs which is executing this workflow from main branch only. So others PRs theoretically should not affects our workflow security posture.

[maze88]

He needs to gain GH_TOKEN first, but he should be blocked on the first step which checks his membership

What if I create an MR which changes that first step?

The current trigger configuration doesn't trigger on PRs, so shouldn't this not be a problem?

And either way - we can configure the repository (Settings -> Actions -> General -> Approval for running fork pull request workflows from contributors to Require approval for all external contributors.

[adrianchiris]

is it GITHUB_TOKEN ?

[adrianchiris]

need to make sure the GITHUB_TOKEN used in network-operator is sufficient.

[adrianchiris]

i dont think this is needed.

this workflow is only triggered by other workflows not PRs.
the other workflow needs to have the needed ppermissions in order to trigger workflow in this repo.
currently only members of Mellanox org can trigger workflows for this project (i just modfied this in setting)

[adrianchiris]

are we using this env var in the job ?

[maze88]

@adrianchiris see my comment from the original line 33 in this file:

# token must be explicitly set here for push to work in following step

@heyvister1 , although you renamed the secret variable (in line 33) - perhaps it's worth preserving the comment (unless you tested that after your change the token no longer needs to be explicitly set?).

[heyvister1]

No need to fork docs repo, since there is already an existing fork for nvidia-ci-cd user