Update `kubernetes-client` organization to allow Github Actions to create pull requests

[brendandburns]

Organization or Repo

kubernetes-client

User affected

all users

Describe the issue

I think in the move to GH enterprise, an organization permissions change occurred which is preventing our github actions in the kubernetes-client/java repository (and probably all other repositories) from sending PRs. In particular, this is blocking our ability to regenerate new code.

The box in the repository settings to enable this for a github action is greyed out, and I believe this is because the organzational settings are restricted as described here:

https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization

Can we update the kubernetes-client organization to allow github actions to send PRs?

Thanks!

[brendandburns]

/assign @kubernetes/owners

[brendandburns]

Friendly ping on this one since it is blocking our ability to generate the 1.31 client.

[dims]

Also for kubernetes-sigs as well please! these actions used to work and don't any more

• https://github.com/kubernetes-sigs/provider-aws-test-infra/actions
• https://github.com/kubernetes-sigs/hydrophone/actions

[brendandburns]

cc @Priyankasaggu11929 @cblecker

Friendly Friday ping on this. Thanks!

[cblecker]

Hey @brendandburns @dims !

I apologize that this response was delayed, and that this change disrupted existing workflows without appropriate notice. You are correct that when we migrated all the orgs into the enterprise, the enterprise-wide policies started taking effect. For other orgs, this setting had already been disabled, but it seems it wasn't on the @kubernetes-client org.

The GitHub Admin Team, along with the SRC, has previously identified some issues with how GitHub Actions was being used in ways that created potential security concerns. As a result, one of the security harding measures that was implemented was disabling the ability for GitHub Actions to do certain write actions including creating PRs and approving code to merge. It seems that this setting wasn't ubiquitously applied across all orgs, and when we brought everything into the enterprise and it started to be enforced, broke a couple workflows including the one you describe above.

At this time, we are not looking at reverting the change to the setting as it weakens the project's security posture. We would be happy to collaborate on alternatives, such as prow jobs, to enable this type of functionality without the use of GitHub Actions.

[brendandburns]

@cblecker we currently use github actions to regenerate code from Kubernetes Swagger. What is the current approach that you suggest? I'm not sure this is something that prow really wants to take on (nor am I sure that is the right solution)

And imho restricting this setting doesn't add any additional security, because I can just add my own GITHUB_TOKEN to my github action's secrets and push PRs using my credentials (which is arguably way less secure) so I'm not sure that this accomplishes much.

[brendandburns]

I wanted to also clarify that these actions aren't run on PRs they are manually triggered and they can only be triggered by the repo owners, so I think that some of the security concerns don't apply.

[brendandburns]

@cblecker friendly ping on this as it is blocking/making more difficult the generation of Kubernetes clients.

[brendandburns]

fwiw, this is also blocking the ability to automatically send PRs back to the repository after we cut a release.

@cblecker we really need to revisit this policy as it is blocking necessary automation. There's a lot of tasks for which prow is not the right solution.

[brendandburns]

Actually, this is worse than that, it is actually blocking our ability to cut a release at all:

https://github.com/kubernetes-client/java/actions/runs/11262193200/job/31317326994

Moving to a manual process for releasing this client is a bad, less secure, idea. Please advise about how you think we should do this.