/assign @dcbw @caseydavenport @thockin @liggitt

Although we discussed this potential change prior to announcing #103675, we wanted to try to get a broader consensus before committing to this change. Unfortunately the corresponding change to EndpointSlices is not sufficient since the EndpointSlice mirroring controller translates Endpoints to EndpointSlices. That means that we need to restrict write access to both to make a meaningful difference.

Since write access to Endpoints and EndpointSlices results in a form of cross-namespace access, it seems inappropriate to include them in the aggregate-to-edit role. Although this represents a breaking change, it would not be the first time we've removed capabilities from the aggregated roles.

/hold

For discussion

/retest

The release note needs to:

• explain the impact to upgraded existing clusters (none)
• provide super-clear guidance for a cluster admin that needs to continue granting this access via the edit/admin roles and doesn't care about the exposure

Ideally, we would provide an example clusterrole they could create that would get aggregated into the edit/admin roles if they wanted to keep the status quo and the CVE did not apply to their environment (not multi-tenant, not using network policy, etc):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    kubernetes.io/description: |-
      Add endpoints and endpointslices write permissions to the edit and admin roles.
      These were removed by default in 1.22 because of CVE-2021-25740. See http://issue.k8s.io/103675.
      This can allow endpoint writers to direct LoadBalancer or Ingress implementations 
      to expose backend IPs that would not otherwise be accessible, and can circumvent 
      network policies or security controls intended to prevent/isolate access to those backends.
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  name: custom:aggregate-to-edit:endpoints
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["create", "delete", "deletecollection", "patch", "update"]
  - apiGroups: ["discovery.k8s.io"]
    resources: ["endpointslices"]
    verbs: ["create", "delete", "deletecollection", "patch", "update"]

/approve

I will be AFK for a few days and wanted to be clear on my feelings on it.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott, thockin

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

The pull request process is described here

/lgtm

/retest

Unless anyone has any hesitation here, I'm planning to remove the hold on this PR in a couple hours.

Created follow up docs PR, updated release note per @liggitt's guidance, and have not heard any hesitancy about merging this in. Given that, I'm going to remove the hold on this.

/hold cancel

/retest