If you decide to run with the RBAC authorizer, tools like kubeadm run the control plane components with credentials that have the required permissions out of th

If you decide to run with the RBAC authorizer, tools like kubeadm run the control plane components with credentials that have the required permissions out of the box. If you're using your own deployment/setup, you'll want to consult https://kubernetes.io/docs/admin/authorization/rbac/#core-component-roles https://kubernetes.io/docs/admin/authorization/rbac/#core-co... to either give standard user/group names to your components, or grant the appropriate roles to custom user/group names. Once your control plane is running, granting API access to other apps that need it is typically a matter of creating a service account, setting that service account in the pod spec, and granting the service account a role with sufficient access. See https://kubernetes.io/docs/admin/authorization/rbac/#service-account-permissions https://kubernetes.io/docs/admin/authorization/rbac/#service... Finally, if you're upgrading an existing cluster, and want to turn on RBAC authorization, there are tips at https://kubernetes.io/docs/admin/authorization/rbac/#upgrading-from-15 https://kubernetes.io/docs/admin/authorization/rbac/#upgradi... for easing the transition.