Automatic updates to the list of allowed actions

[barchw]

Description
Third party actions and their versions that are allowed to be used in Kyma organisation repositories are stored in docs/contributing/assets/allowed_actions.json. This list is often outdated, making the process of being up-to-date with the actions releases problematic.

This issue proposes a solution of having an automation that would create a PR to this list, that could later be approved by Kyma Security team (dependabot alike)

Reasons
Being up-to-date with actions.

References

• Silently failing GitHub Action Workflows because of failed allowed version propagation  #911

[strekm]

@TorstenD-SAP and myself meet to discuss this issue and we have following:

• merge of PR should trigger workflow executing a script adding allowed GH Actions
• above workflow should notify on failure
  Idea to improve PR review would be to investigate if auto approval is possible when only GH Action is updated to newer version. Full approval would be only needed if completely new GH Action is added. Depending on outcome restructuring might be necessary.
  In the case of an automatic approval the script should be capable to check if GH Action version is submitted in proper format and if other things are submitted in "compliant" way (e. g. security review was performed).

[strekm]

another comment on my side: any validations should be done on PR. if that is failing merge should be blocked. main should be always in clean state and automation is only propagating this configuration
that kind of validation should be in place even if we do not have auto approval

[Sawthis]

@TorstenD-SAP @strekm @barchw
Some questions from my side:

• Should only the newest version of the GitHub action be allowed? In this case, after the update, all workflows using the older version will be blocked.
• @TorstenD-SAP, do we need to be so strict about the version of the GitHub actions? Even in the internal GitHub, all versions of the GitHub actions are allowed. I will send you a link, as I can't link it here.
• Should the automation update the list of the allowed actions in the Github organization settings based on the content of allowed_actions.json?

[mrCherry97]

My general question is do we really need it for all of the workflows? I understand restrictions for Build workflows, but I don't get why we need to have restrictions for workflows that are just running for example tests or some other check related to development only. For example dev deps are not scanned in images or you can triage vulnerabilities related to dev deps, and we need restricted actions for running tests?

The second question is how we are maintaining this allowed_actions.json file, how can I add something new, and who can I ask for approval of my change in case @TorstenD-SAP will be on vacation, sick leave, or whatever case he will be offline. Currently, this is a "one-man army".

[barchw]

Responding to @Sawthis questions:

1. Should only the newest version of the GitHub action be allowed? In this case, after the update, all workflows using the older version will be blocked.

I would say this is not really possible to achieve without breaking already running workflows, especially when module teams are supporting different release branches.

3. Should the automation update the list of the allowed actions in the Github organization settings based on the content of allowed_actions.json?

That's what's expected if this issue is implemented. Right now, from what I understood this process in manual. What we would want, is an easy way to update this file, and have it updated in our module repo immediately.

What @mrCherry97 mentions, that right now all changes to this file have to be approved by @TorstenD-SAP, and having one person need to approve all version upgrades is the real problem why we are even coming with this issue, so this is the thing we would like to resolve.

[Sawthis]

So currently we have 2 issues with this process:

• @TorstenD-SAP is the only one who can approve new versions of the GitHub actions and update them in the organization settings
• lack of automated update of the Github action versions, personally I would vote for the solution like is used in the internal Github that all versions are allowed

Even if we automate the update of the Github action versions, it will require approval by @TorstenD-SAP, and it's not scalable. We can implement auto-approve and auto-merge features for it, but then it will be the same as allowing all versions of the given Github actions.

First of all, I would vote to have more people who can approve of the allowed Github action versions update. Maybe @kyma-project/kyma-steering-committee ?

As a second step, I would allow the use of all versions of the given Github action as it is done in the internal Github. Then, we can automate updates from the list of the allowed actions to the organization settings. Or just generate a list in the Github action to make it easier for the reviewer to update the organization settings.

[TorstenD-SAP]

As a second step, I would allow the use of all versions of the given Github action as it is done in the internal Github.

I do not know who decided to allow every version of an approved action in the internal Github, but I want to object to do it in that way. It is a clear guidance from Github itself to pin actions to a full length commit SHA (https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions). As you read further down on the page I shared before, Github recommends to audit the code of an action and this is also required in our guidelines (https://github.com/kyma-project/community/blob/main/docs/contributing/05-gh-actions.md#perform-security-review).

@TorstenD-SAP is the only one who can approve new versions of the GitHub actions and update them in the organization settings

There is already a cli tool to update the list of allowed actions. What is missed is to turn this into a Github action to automate the update of the list of allowed actions. If this is done, we can simply add more people to approve the changes on the allowed actions.

[TorstenD-SAP]

@Sawthis

Should only the newest version of the GitHub action be allowed? In this case, after the update, all workflows using the older version will be blocked.

Even this would be great from a security pov it is not the case atm. Supporting only the latest version immediately will for sure break a lot of workflows.

Should the automation update the list of the allowed actions in the Github organization settings based on the content of allowed_actions.json?

Yes, this is the idea of that file.

[Sawthis]

As it was announced by @TorstenD-SAP .

Starting from March 3rd, all Github Actions will be allowed without restrictions.