Automatic merge from submit-queue (batch tested with PRs 41357, 41178, 41280, 41184, 41278)
Switch RBAC subject apiVersion to apiGroup in v1beta1
Referencing a subject from an RBAC role binding, the API group and kind of the subject is needed to fully-qualify the reference.
The version is not, and adds complexity around re-writing the reference when returning the binding from different versions of the API, and when reconciling subjects.
This PR:
* v1beta1: change the subject `apiVersion` field to `apiGroup` (to match roleRef)
* v1alpha1: convert apiVersion to apiGroup for backwards compatibility
* all versions: add defaulting for the three allowed subject kinds
* all versions: add validation to the field so we can count on the data in etcd being good until we decide to relax the apiGroup restriction
```release-note
RBAC `v1beta1` RoleBinding/ClusterRoleBinding subjects changed `apiVersion` to `apiGroup` to fully-qualify a subject. ServiceAccount subjects default to an apiGroup of `""`, User and Group subjects default to an apiGroup of `"rbac.authorization.k8s.io"`.
```
@deads2k @kubernetes/sig-auth-api-reviews @kubernetes/sig-auth-pr-reviews
Automatic merge from submit-queue
give nodes update/delete permissions
delete permission is logically paired with create permission (and is used during self-registration scenarios when a node has been restarted and an existing node object has a mismatched externalID)
we already need to scope update nodes/status permission to only let a node update itself, and we would scope these at the same time.
fixes https://github.com/kubernetes/kubernetes/issues/41224
Automatic merge from submit-queue (batch tested with PRs 40574, 40806, 40308, 40771, 39440)
Add bootstrap cluster role for external pv provisioners
The set of permissions an external provisioner https://github.com/kubernetes/kubernetes/pull/30285 running as a pod will need. Technically in order to dynamically provision PVs one doesn't need to "update" PVCs or "watch" events but the controller https://github.com/kubernetes-incubator/nfs-provisioner/tree/master/controller we are recommending people use does those things to: set lock annotations on PVCs and watch `ProvisioningSucceeded`/`ProvisioningFailed` events.
Some external provisioners may need additional permissions, for example nfs-provisioner requires "get" access to Services and Endpoints when run "statefully." I think in that case we would recommend creating a new ClusterRole specific to that provisioner, using this as a base?
(This was to be a part of my redo/fix of the external e2e test https://github.com/kubernetes/kubernetes/pull/39545 but I'm submitting it as a separate PR for now due to some issues I had with running nfs-provisioner on gce.)
@kubernetes/sig-auth-misc ?
Automatic merge from submit-queue
Include "ingresses" resource in RBAC bootstrap roles
The bootstrap RBAC roles "admin", "edit", and "view" should all be able to apply their respective access verbs to the "ingresses" resource in order to facilitate both publishing Ingress resources (for
service administrators) and consuming them (for ingress controllers).
Note that I alphabetized the resources listed in the role definitions that I changed to make it easier to decide later where to insert new entries. The original order looked like it may have started out alphabetized, but lost its way. If I missed an intended order there, please advise.
I am uncertain whether this change deserves mention in a release note, given the RBAC feature's alpha state. Regardless, it's possible that a cluster administrator could have been happy with the previous set of permissions afforded by these roles, and would be surprised to discover that bound subjects can now control _Ingress_ resources. However, in order to be afflicted, that administrator would have had to have applied these role definitions again which, if I understand it, would be a deliberate act, as bootstrapping should only occur once in a given cluster.
The bootstrap RBAC roles "admin", "edit", and "view" should all be
able to apply their respective access verbs to the "ingresses"
resource in order to facilitate both publishing Ingress resources (for
service administrators) and consuming them (for ingress controllers).
Automatic merge from submit-queue
add patch RS to deployment controller
Found in http://gcsweb.k8s.io/gcs/kubernetes-jenkins/logs/ci-kubernetes-e2e-gci-gce/2841/artifacts/bootstrap-e2e-master/, `RBAC DENY: user "system:serviceaccount:kube-system:deployment-controller" groups [system:serviceaccounts system:serviceaccounts:kube-system system:authenticated] cannot "patch" on "replicasets.extensions/" in namespace "e2e-tests-deployment-3rj5g"
`
@kubernetes/sig-auth-misc
Automatic merge from submit-queue
Give replicaset controller patch permission on pods
Needed for AdoptPod/ReleasePod
Fixes denials seen in autoscaling test log:
`RBAC DENY: user "system:serviceaccount:kube-system:replicaset-controller" groups [system:serviceaccounts system:serviceaccounts:kube-system system:authenticated] cannot "patch" on "pods./"`
Automatic merge from submit-queue (batch tested with PRs 38212, 38792, 39641, 36390, 39005)
Allow node-controller to update node status
ref: #39639
* adds required permissions to node-controller
* fixes typo in role name for pod-garbage-collector role
* adds event watching permissions to persistent volume controller
* adds event permissions to node proxier
