Add [email protected] group

[ahrtr]

Resolve https://github.com/kubernetes/community/issues/7739

[MadhavJivrajani]

/assign @cblecker @nikhita

[upodroid]

I have a better idea, why don't we add the etcd.io domain to the kubernetes.io Workspace as an alias domain and then recreate the same mailing list?

[ahrtr]

I have a better idea, why don't we add the etcd.io domain to the kubernetes.io Workspace as an alias domain and then recreate the same mailing list?

Sounds like a good idea, so we can continue to use [email protected]? cc @jmhbnz @serathius @spzala @wenjiaswe

Will it have any impact on https://etcd.io/?

[upodroid]

No, there is a separate issue to recreate the etcd.io DNS zone in a Google Cloud DNS project that the community owns similar to https://github.com/kubernetes/k8s.io/tree/main/dns.

[ahrtr]

Thanks for the feedback. Let's see others' feedback on we add the etcd.io domain to the kubernetes.io Workspace as an alias domain and then recreate the same mailing list.

Could you provide detailed guide on how to do it? Or can we add a task in https://github.com/kubernetes/k8s.io/issues/6102?

[upodroid]

1. Send the complete DNS zone for etcd.io to sig-k8s-infra via Slack
2. We'll recreate the zone in GCP with zero modifications and give you a set of NS records to configure with your domain provider. I'm assuming the domain is owned by CNCF/LF. If not, I would probably fix that as well.
3. Unlink etcd.io from the current Google Workspace subscription
4. Someone from @kubernetes/steering-committee needs to add the domain to the kubernetes.io Google Workspace. They will receive a set of DNS records to verify ownership.
5. We'll add the DNS records for verification and the domain is now available for use.
6. Update this PR to use the previous email
7. Merge this PR.

[spzala]

Thanks for the feedback. Let's see others' feedback on we add the etcd.io domain to the kubernetes.io Workspace as an alias domain and then recreate the same mailing list.

Could you provide detailed guide on how to do it? Or can we add a task in #6102?

Thanks @ahrtr @upodroid Also CC'ing @mrbobbytables @BenTheElder for their thoughts, thanks!

[mrbobbytables]

I think it's a good move, theres been a separate thread on what to do with the etcd google workspace so this would wrap everything up nicely.

/cc

[spzala]

I think it's a good move, theres been a separate thread on what to do with the etcd google workspace so this would wrap everything up nicely.

/cc

Sounds good, thanks so much @mrbobbytables !! @ahrtr thanks for driving this, I am looking at the next steps in this direction.

[cblecker]

Another thing to consider: has sig-etcd spoken with the Kubernetes SRC about this? Now that etcd is a part of the Kubernetes project, I would expect that vulnerability reporting would flow through them now (it wasn't specifically called out in the charter as something that sig-etcd would do differently).

/hold (adding as the consensus is this PR as is, isn't ready to merge)

[wenjiaswe]

@cblecker I don't know, probably not? Would you please kindly share the point of contact of k8s SRC please?

[BenTheElder]

Good point, maybe we should alias (https://github.com/kubernetes/k8s.io/pull/6542#issuecomment-1983309073) [email protected] to SRC?

@wenjiaswe: https://github.com/kubernetes/committee-security-response#contacting-the-src https://kubernetes.io/security

[spzala]

As etcd is used as stand-alone, we want to make sure users of etcd don't feel restricted to using it with only k8s. If we can use [email protected] alias then using k8s SRC that should be good, IMHO. This will keep things simpler from any maintenance perspective and will keep SRC in aware of any etcd security issues. However, that means, we may want etcd maintainer representation in the SRC or SRC can simply forward issues to the maintainers group (I guess either should work). I can reach out to SRC if using SRC sounds good to you @ahrtr @wenjiaswe @serathius @jmhbnz cc @cblecker @BenTheElder Thanks!

[spzala]

As etcd is used as stand-alone, we want to make sure users of etcd don't feel restricted to using it with only k8s. If we can use [email protected] alias then using k8s SRC that should be good, IMHO. This will keep things simpler from any maintenance perspective and will keep SRC in aware of any etcd security issues. However, that means, we may want etcd maintainer representation in the SRC or SRC can simply forward issues to the maintainers group (I guess either should work). I can reach out to SRC if using SRC sounds good to you @ahrtr @wenjiaswe @serathius @jmhbnz cc @cblecker @BenTheElder Thanks!

I have reached out to SRC but haven't yet heard back I guess because of KubeCon travel next week. I will follow up, but it will be good if you get an opportunity to discuss this in person with any SRC member(s) at the KubeCon @ahrtr @wenjiaswe Thanks!

[upodroid]

I met James in person.

We need to migrate all the GCP projects in the etcd.io GCP org before we decommission the gsuite org and move the domain to kubernetes.io Google Workspace.

I'll work with James & other SIG K8s Infra leads on migrating those projects to our org.

[mrbobbytables]

I tried to add etcd.io as an alias domain to the kubernetes workspace, but it will not let me proceed because its currently associated with another workspace. -_-

[ahrtr]

but it will not let me proceed because its currently associated with another workspace. -_-

cc @idvoretskyi

[cblecker]

We need to cut some other things over first. This is currently pending on me (and I'm in turn waiting for something from CNCF staff).

/assign /hold

[idvoretskyi]

A quick check here on a current state of things, @cblecker :)

[BenTheElder]

What happened with this? Please let us know in #sig-k8s-infra at slack.k8s.io if there's anything blocked on us.

[jmhbnz]

What happened with this? Please let us know in #sig-k8s-infra at slack.k8s.io if there's anything blocked on us.

Hey Team - @upodroid and I met a couple weeks ago to continue stepping through the migration of gcp projects. We got stuck on permissions and needed to reach out to the Linux Foundation listed org admin for the etcd-development gcp project.

I did that on Kubernetes slack but checking back we haven't had a reply so I have just followed up with an email.

[jmhbnz]

Update: After a call today with @upodroid and Shah Ahmadzai from the Linux Foundation 2/3 etcd GCP projects have now been migrated to the Kubernetes org and I believe billing account has also now been updated.

The one remaining project etcd-development we still have a credentials/permissions issue with and are continuing to work with the Linux Foundation on.

[upodroid]

Also, we got access to the etcd.io Google Workspace and are currently working on delinking the domain from there and attaching it to the kubernetes.io Google Workspace.

[ahrtr]

Resolve all comments, thanks all for the help!

[ahrtr]

Note the test case TestGroupConventions requires,

• the group name and email match. The mail ID is [email protected], but the name "security" has already been used by [email protected], so I use the name "etcd-security"
• the email must have suffix "@kubernetes.io". I updated the test case.

https://github.com/kubernetes/k8s.io/blob/86d9aa9c2b5418db0aecb684c6289bf7280770a7/groups/groups_test.go#L170

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahrtr, MadhavJivrajani, upodroid

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~groups/OWNERS~~ [upodroid]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[spzala]

Resolve all comments, thanks all for the help!

+1 Thank you so much @ahrtr @cblecker and everyone!!!

[spzala]

@upodroid received the test email :) Thank you so much!