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

[heyvister1]

Since custom GH secrets are not propagated for forked PRs
A new step has been added to verify that actor is a member of Mellanox/cloud-orchestration team

[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.