},
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",
            "version": "v1"
          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",
            "version": "v1alpha1"
          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",

- Added RBAC reconcile commands with `kubectl auth reconcile -f FILE`. When
  passed a file which contains RBAC roles, rolebindings, clusterroles, or
  clusterrolebindings, this command computes covers and adds the missing rules.
  The logic required to properly apply RBAC permissions is more complicated

---
# Source: calico/templates/calico-node-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: calico-node
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: calico-node
subjects:
- kind: ServiceAccount
  name: calico-node
  namespace: kube-system
---
# Source: calico/templates/calico-node-rbac.yaml

#### **RBAC**

*   New permissions have been added to default RBAC roles ([#52654](https://github.com/kubernetes/kubernetes/pull/52654),[ @liggitt](https://github.com/liggitt)):
    *   The default admin and edit roles now include read/write permissions
    *   The view role includes read permissions on poddisruptionbudget.policy resources.

    * rbac.authorization.k8s.io/v1alpha1

    * settings.k8s.io/v1alpha1

    * If you wish to continue using them in v1.8, please enable them explicitly using the `--runtime-config` flag on the apiserver (for example, `--runtime-config="rbac.authorization.k8s.io/v1alpha1,settings.k8s.io/v1alpha1"`)

([#57613](https://github.com/kubernetes/kubernetes/pull/57613), [@mtaufen](https://github.com/mtaufen))

* The boostrapped RBAC role and rolebinding for the `cloud-provider` service account is now deprecated. If you're currently using this service account, you must create and apply your own [RBAC policy](https://kubernetes.io/docs/admin/authorization/rbac/) for new clusters. ([#59949](https://github.com/kubernetes/kubernetes/pull/59949), [@nicksardo](https://github.com/nicksardo))

- Kubeadm: avoided uploading a defaulted flag value "--authorization-mode=Node,RBAC" for the kube-apiserver in the ClusterConfiguration stored in the "kube-system/kubeadm-config" ConfigMap. "Node,RBAC" are already the kubeadm defaults for this flag, so this action is redundant. ([#123555](https://github.com/kubernetes/kubernetes/pull/123555), [@neolit123](https://github.com/neolit123))

          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",
            "version": "v1"
          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",
            "version": "v1alpha1"
          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",

 - `kubeadm`: a separate "super-admin.conf" file is now deployed. The User in `admin.conf` is now bound to a new RBAC Group `kubeadm:cluster-admins` that has `cluster-admin` `ClusterRole` access. The User in `super-admin.conf` is now bound to the `system:masters` built-in super-powers / break-glass Group that can bypass RBAC. Before this change, the default `admin.conf` was bound to `system:masters` Group, which was undesired. Executing `kubeadm init phase kubeconfig...

          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",
            "version": "v1"
          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",
            "version": "v1alpha1"
          },
          {
            "group": "rbac.authorization.k8s.io",
            "kind": "DeleteOptions",