+1 as a Release Manager

We could also reuse existing service accounts and grant them permissions to push to those buckets.

We could also reuse existing service accounts and grant them permissions to push to those buckets.

Would it be better security wise to have a dedicated service account per bucket?

We could also reuse existing service accounts and grant them permissions to push to those buckets.

Would it be better security wise to have a dedicated service account per bucket?

it depends on the entities that use these service accounts. As long we are inside the GCP perimeter, IMHO, reuse existing service accounts is fine.
However, it's recommended to use short-lived tokens rather than JSON creds.

However, it's recommended to use short-lived tokens rather than JSON creds.

How would that work, for example when using GitHub actions?

The only service account I can see is k8s-infra-promoter@k8s-artifacts-prod.iam.gserviceaccount.com which has write access to the buckets. Should we use this one?

I prefer that we create a new service account, especially because this SA might be used outside Prow (e.g. with GitHub Actions)

However, it's recommended to use short-lived tokens rather than JSON creds.

How would that work, for example when using GitHub actions?

I remember @upodroid mentioned this article. https://cloud.google.com/blog/products/identity-security/enabling-keyless-authentication-from-github-actions which in resume means the Github Actions will assume an existing SA.

We can start with a new and single SA to cover all the buckets handled by RelEng.

From the convo on Slack, we can start with one single GCP Service Account to handle artifacts publication.

@xmudrii @saschagrunert Feel free to open PR against the repo and I'll actuate it.

Ref #5997

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale