track the rename of the "system:masters" group

[neolit123]

Kubernetes includes a stock "system:masters" group that have full access to cluster resources:
https://kubernetes.io/docs/reference/access-authn-authz/rbac/

kubeadm binds its administrator account to this group:
https://github.com/kubernetes/kubernetes/blob/e45b8bfe0f45c276537bb8e927b2ae5af8466590/cmd/kubeadm/app/constants/constants.go#L168

this ticket is created with the assumption that the group name will be changed at some point (based on the efforts by wg-naming), potentially by introducing a new group that has the same level of access and deprecating the old group.

on the side of kubeadm we'd have to track this effort and adapt kubeadm to handle the introduction of the new group.

k/k issue: (NONE exists yet?)
plan: TODO

[justaugustus]

@neolit123 -- do we have any updates on this one?

[neolit123]

@justaugustus
no, this one is on sig-auth.

[justaugustus]

Ping @kubernetes/sig-auth-feature-requests

[enj]

Uh, I did not know we were planning on changing this group. I do not think we can ever safely stop supporting system:masters because it could break existing clusters. That string is considered special in many places in the k/k code.

[celestehorgan]

@kubernetes/sig-architecture-leads – @enj brings up a great point above. For reasons I think are obvious though we'd like to at least remove system:masters going forward, even if we need to maintain backwards compatibility. Thoughts?

[dims]

@celestehorgan @enj i'd request sig-auth to take the lead here propose a plan that can work (some sort of switch to help existing clusters + a more forward looking better name may be?)

[neolit123]

the topic for k8s core needs a kubernetes/kubernetes issue.
this one is for kubeadm.

[enj]

We discussed this extensively in a recent sig-auth meeting. I have the AI to distill the discussion into a k/k issue that outlines the available options. That would enable the creation of the KEP needed to address this (as best as we can).

[justaugustus]

@enj @neolit123 -- How are we doing w/ discussions on next steps?

[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

[neolit123]

i don't know if we have a k/k issue.
/remove-lifecycle stale

[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

[neolit123]

/lifecycle frozen

[ibihim]

We discussed this extensively in a recent sig-auth meeting. I have the AI to distill the discussion into a k/k issue that outlines the available options. That would enable the creation of the KEP needed to address this (as best as we can).

Based on this, we have an action item open to create an issue for that or do we want to close it? @enj

[neolit123]

@ibihim please post a link to the new issue once it's created here.