kubernetes.io Google Workspace automation

[spiffxp]

Problem Statement

Lack of API access to our existing googlegroups.com infrastructure is creating entirely too much toil (ref: kubernetes/community#3541). Some specific examples that come to mind:

• ensuring community docs aren't stranded when original owners move on from the project
• managing community mailing lists
• managing calendar invites
• using mailing list membership as one method of SIG membership (ref: SIGs need a Roster on who is on a SIG community#5854)

In addition, lack of easily available API access to our kubernetes.io Google Workspace is preventing wg-k8s-infra from accomplishing a few tasks:

• fully identifying and troubleshooting IAM access issues (ref: Allow troubleshooting group memberhip k8s.io#1695)
• full ownership of the kubernetes.io billing report(ref: Ensure k8s-infra billing report and data sources are owned by and billed to community k8s.io#1625)
• ability to create community-owned Data Studio reports for dashboards such as top flakes, job health, etc. (ref: Investigate community-accessible Data Studio reports and data sources k8s.io#1590)

Proposed Solution

I would like to scope out and propose a solution that involves wg-k8s-infra taking on ownership and administration of the kubernetes.io GSuite instance, with appropriate tools and automation to provide as much PR-based self-service as possible.

Some items I would propose to address sooner vs. later:

• granting wg-k8s-infra gcp org admins super-admin privileges on the kubernetes.io Google Workspace
• a migration plan for moving mailing lists from googlegroups.com to kubernetes.io

To help me do this, I would like to start by requesting an account wg-k8s-infra-admin@kubernetes.io with super admin privileges, equivalent to the access held by the scN@kubernetes.io accounts that currently manage the kubernetes.io Google Workspace. This will allow me to create 1-2 other accounts to use as pilots, as well as the ability to grant them appropriate API access. AFAICT there is a one-to-one mapping between Google Workspace users and service accounts they delegate to, but if not, I'm happy to stick to 1 user.

As proof that I'm not asking for cart-blanche, I have an old not-fully-formed proposal I started putting together back in March 2021. Based on feedback I gathered while shopping it around privately, I don't consider it ready for review, but it can give you an idea of where I am thinking of heading.

Cost

Based on back-of-napkin numbers I was running in March, I could be asking for something in the ballpark of O($100/yr) best-case, to O($30k/yr) worst-case. It seems highly unlikely that worst-case costs would be necessary. It was unclear to me whether this was coming out of the GCP Credits donated to wg-k8s-infra, or out of CNCF directly.

Open Questions

• What is the actual concrete proposal?
• What is the proposed timeline?

Next Steps

• Provision a wg-k8s-infra-admin@kubernetes.io account that @spiffxp can use to pilot/trial appropriate API access
• Draft a concrete proposal with at least two alternatives and cost options
• Get approval to move forward

Other Considerations, Notes, or References

• An example of what we went through to setup google group membership automation: Manage Google Group memberships via API k8s.io#228
• Google Workspace for Developers: Getting started as a Workspace developer
• Google Workspace for Developers: Authentication and Authorization overview
• Google Workspace Admin SDK: Perform Google Workspace Domain-Wide Delegation of Authority
• Google Workspace Admin Help: Manage shared drive users and activity
• Google Workspace Admin Help: Shared drive access levels
• Google Workspace Admin Help: Drive audit log

/committee steering
/wg k8s-infra
/sig contributor-experience
/priority important-longterm

[spiffxp]

/assign @dims @mrbobbytables @parispittman
To help out with the "requesting an account wg-k8s-infra-admin@kubernetes.io with super admin privileges, equivalent to the access held by the scN@kubernetes.io accounts" piece

EDIT: I plan on being the sole holder of these credentials as a steering emeritus, until I can identify less privileged levels of access that steering is comfortable delegating beyond myself

[dims]

/approve

yes, let's please go ahead with this @spiffxp !

[mrbobbytables]

+1 from me as well, this would help out in a lot of areas.

[parispittman]

+1

[ehashman]

I would like to scope out and propose a solution that involves wg-k8s-infra taking on ownership and administration of the kubernetes.io GSuite instance

Since WGs are supposed to eventually wrap up, will transitioning ownership to a permanent group like a SIG be a later responsibility of WG k8s Infra?

[spiffxp]

Will transitioning ownership to a permanent group like a SIG be a later responsibility of WG k8s Infra?

Yeah, I see this going one of two ways:

• all responsibilities are sharded out to the appropriate SIG, (e.g. the automation code and running of it is owned by SIG ContribEx (much as they own slack-infra right now))
• the WG becomes a SIG

I would be happy to transition full ownership of the Google Workspace Groups automation to SIG ContribEx today except for the fact that it lacks the rule-based exclusion that slack-infra has which allows for better delegation to subdir OWNERS. It's sortof why we have a ContribEx TL as one of the root-level approvers for groups changes.

[spiffxp]

OK I have an account, it's protected by 2FA. Going to need some time to come back to you with a more fully formed proposal, my hope is by the start of v1.23

[parispittman]

kubernetes/community#5877

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[mrbobbytables]

/remove-lifecycle stale
/lifecycle frozen