+Kubernetes RBAC API discovery roles
+
+
+| ClusterRole Bawaan |
+ClusterRoleBinding Bawaan |
+Deskripsi |
+
+
+| system:basic-user |
+system:authenticated group |
+Mengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, peran ini juga terikat pada system:unauthenticated secara bawaan. |
+
+
+| system:discovery |
+system:authenticated group |
+Mengizinkan akses baca pada _API discovery endpoints_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, peran ini juga terikat pada system:unauthenticated secara bawaan. |
+
+
+| system:public-info-viewer |
+system:authenticated and system:unauthenticated groups |
+Mengizinkan akses baca pada informasi yang tidak sensitif tentang klaster. Diperkenalkan pada Kubernetes v1.14. |
+
+
+
+### Peran Pengguna
+
+Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk peran pengguna.
+Ini termasuk peran super-user (`cluster-admin`), peran yang dimaksudkan untuk diberikan akses seluruh klaster dengan
+menggunakan ClusterRoleBinding, dan peran yang dimaksudkan untuk diberikan pada namespace tertentu
+dengan menggunakan RoleBinding (`admin`, `edit`, `view`).
+
+ClusterRoles menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada peran `admin`, `edit`, atau `view`, buat sebuah CLusterRole
+dengan satu atau lebih label berikut:
+
+```yaml
+metadata:
+ labels:
+ rbac.authorization.k8s.io/aggregate-to-admin: "true"
+ rbac.authorization.k8s.io/aggregate-to-edit: "true"
+ rbac.authorization.k8s.io/aggregate-to-view: "true"
+```
+
+
+
+
+| ClusterRole Bawaan |
+ClusterRoleBinding Bawaan |
+Deskripsi |
+
+
+| cluster-admin |
+system:masters group |
+Mengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya.
+Ketika digunakan pada ClusterRoleBinding, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh namespace.
+Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada namespace ikatan peran, termasuk namespace itu sendiri. |
+
+
+| admin |
+None |
+mengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah namespace menggunakan RoleBinding.
+Jika digunakan dalam RoleBinding, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah namespace,
+termasuk kemampuan untuk membuat peran dan ikatan peran dalam namespace.
+Peran ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke namespace itu sendiri. |
+
+
+| edit |
+None |
+Mengizinkan akses baca/tulis pada seluruh objek dalam namespace.
+
+Peran ini tidak memungkinkan untuk melihat dan merubah peran dan ikatan peran.
+Namun, peran ini memungkinkan untuk mengakses secret dan menjalankan pod seperti ServiceAccount dalam namespace,
+sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di namespace.
+ |
+
+
+| view |
+None |
+Mengizinkan akses baca untuk melihat hampir seluruh objek dalam namespace.
+
+Ini tidak memungkinkan untuk melihat peran dan ikatan peran.
+
+Peran ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan
+akses ke kredensial ServiceAccount dalam namespace, yang akan memungkinkan akses API sebagai
+ServiceAccount apapun di namespace (bentuk eskalasi hak istimewa).
+ |
+
+
+
+### Core component roles
+
+
+
+
+| Default ClusterRole |
+Default ClusterRoleBinding |
+Description |
+
+
+| system:kube-scheduler |
+system:kube-scheduler user |
+Allows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component. |
+
+
+| system:volume-scheduler |
+system:kube-scheduler user |
+Allows access to the volume resources required by the kube-scheduler component. |
+
+
+| system:kube-controller-manager |
+system:kube-controller-manager user |
+Allows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component.
+The permissions required by individual controllers are detailed in the controller roles. |
+
+
+| system:node |
+None |
+Allows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects.
+
+You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them.
+
+The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8.
+ |
+
+
+| system:node-proxier |
+system:kube-proxy user |
+Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component. |
+
+
+
+### Other component roles
+
+
+
+
+| Default ClusterRole |
+Default ClusterRoleBinding |
+Description |
+
+
+| system:auth-delegator |
+None |
+Allows delegated authentication and authorization checks.
+This is commonly used by add-on API servers for unified authentication and authorization. |
+
+
+| system:heapster |
+None |
+Role for the Heapster component (deprecated). |
+
+
+| system:kube-aggregator |
+None |
+Role for the kube-aggregator component. |
+
+
+| system:kube-dns |
+kube-dns service account in the kube-system namespace |
+Role for the kube-dns component. |
+
+
+| system:kubelet-api-admin |
+None |
+Allows full access to the kubelet API. |
+
+
+| system:node-bootstrapper |
+None |
+Allows access to the resources required to perform
+kubelet TLS bootstrapping. |
+
+
+| system:node-problem-detector |
+None |
+Role for the node-problem-detector component. |
+
+
+| system:persistent-volume-provisioner |
+None |
+Allows access to the resources required by most dynamic volume provisioners. |
+
+
+
+### Roles for built-in controllers {#controller-roles}
+
+The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs
+{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes
+control plane.
+When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller
+using a separate service account.
+Corresponding roles exist for each built-in controller, prefixed with `system:controller:`.
+If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops
+using its own credential, which must be granted all the relevant roles.
+These roles include:
+
+* `system:controller:attachdetach-controller`
+* `system:controller:certificate-controller`
+* `system:controller:clusterrole-aggregation-controller`
+* `system:controller:cronjob-controller`
+* `system:controller:daemon-set-controller`
+* `system:controller:deployment-controller`
+* `system:controller:disruption-controller`
+* `system:controller:endpoint-controller`
+* `system:controller:expand-controller`
+* `system:controller:generic-garbage-collector`
+* `system:controller:horizontal-pod-autoscaler`
+* `system:controller:job-controller`
+* `system:controller:namespace-controller`
+* `system:controller:node-controller`
+* `system:controller:persistent-volume-binder`
+* `system:controller:pod-garbage-collector`
+* `system:controller:pv-protection-controller`
+* `system:controller:pvc-protection-controller`
+* `system:controller:replicaset-controller`
+* `system:controller:replication-controller`
+* `system:controller:resourcequota-controller`
+* `system:controller:root-ca-cert-publisher`
+* `system:controller:route-controller`
+* `system:controller:service-account-controller`
+* `system:controller:service-controller`
+* `system:controller:statefulset-controller`
+* `system:controller:ttl-controller`
+
+## Privilege escalation prevention and bootstrapping
+
+The RBAC API prevents users from escalating privileges by editing roles or role bindings.
+Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use.
+
+### Restrictions on role creation or update
+
+You can only create/update a role if at least one of the following things is true:
+
+1. You already have all the permissions contained in the role, at the same scope as the object being modified
+(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
+2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group.
+
+For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole
+containing that permission. To allow a user to create/update roles:
+
+1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired.
+2. Grant them permission to include specific permissions in the roles they create/update:
+ * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
+ * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group
+
+### Restrictions on role binding creation or update
+
+You can only create/update a role binding if you already have all the permissions contained in the referenced role
+(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role.
+For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding
+to a role that grants that permission. To allow a user to create/update role bindings:
+
+1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired.
+2. Grant them permissions needed to bind a particular role:
+ * implicitly, by giving them the permissions contained in the role.
+ * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole).
+
+For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: role-grantor
+rules:
+- apiGroups: ["rbac.authorization.k8s.io"]
+ resources: ["rolebindings"]
+ verbs: ["create"]
+- apiGroups: ["rbac.authorization.k8s.io"]
+ resources: ["clusterroles"]
+ verbs: ["bind"]
+ resourceNames: ["admin","edit","view"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+ name: role-grantor-binding
+ namespace: user-1-namespace
+roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: ClusterRole
+ name: role-grantor
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+ kind: User
+ name: user-1
+```
+
+When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have.
+To bootstrap initial roles and role bindings:
+
+* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings.
+* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization.
+
+## Command-line utilities
+
+### `kubectl create role`
+
+Creates a Role object defining permissions within a single namespace. Examples:
+
+* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods:
+
+ ```shell
+ kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
+ ```
+
+* Create a Role named "pod-reader" with resourceNames specified:
+
+ ```shell
+ kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
+ ```
+
+* Create a Role named "foo" with apiGroups specified:
+
+ ```shell
+ kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
+ ```
+
+* Create a Role named "foo" with subresource permissions:
+
+ ```shell
+ kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
+ ```
+
+* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name:
+
+ ```shell
+ kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
+ ```
+
+### `kubectl create clusterrole`
+
+Creates a ClusterRole. Examples:
+
+* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods:
+
+ ```shell
+ kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
+ ```
+
+* Create a ClusterRole named "pod-reader" with resourceNames specified:
+
+ ```shell
+ kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
+ ```
+
+* Create a ClusterRole named "foo" with apiGroups specified:
+
+ ```shell
+ kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
+ ```
+
+* Create a ClusterRole named "foo" with subresource permissions:
+
+ ```shell
+ kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
+ ```
+
+* Create a ClusterRole named "foo" with nonResourceURL specified:
+
+ ```shell
+ kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
+ ```
+
+* Create a ClusterRole named "monitoring" with an aggregationRule specified:
+
+ ```shell
+ kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
+ ```
+
+### `kubectl create rolebinding`
+
+Grants a Role or ClusterRole within a specific namespace. Examples:
+
+* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob":
+
+ ```shell
+ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
+ ```
+
+* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp":
+
+ ```shell
+ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
+ ```
+
+* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp":
+
+ ```shell
+ kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
+ ```
+
+### `kubectl create clusterrolebinding`
+
+Grants a ClusterRole across the entire cluster (all namespaces). Examples:
+
+* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root":
+
+ ```shell
+ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
+ ```
+
+* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy":
+
+ ```shell
+ kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
+ ```
+
+* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme":
+
+ ```shell
+ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
+ ```
+
+### `kubectl auth reconcile` {#kubectl-auth-reconcile}
+
+Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file.
+
+Missing objects are created, and the containing namespace is created for namespaced objects, if required.
+
+Existing roles are updated to include the permissions in the input objects,
+and remove extra permissions if `--remove-extra-permissions` is specified.
+
+Existing bindings are updated to include the subjects in the input objects,
+and remove extra subjects if `--remove-extra-subjects` is specified.
+
+Examples:
+
+* Test applying a manifest file of RBAC objects, displaying changes that would be made:
+
+ ```
+ kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
+ ```
+
+* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings):
+
+ ```shell
+ kubectl auth reconcile -f my-rbac-rules.yaml
+ ```
+
+* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings):
+
+ ```shell
+ kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
+ ```
+
+## ServiceAccount permissions {#service-account-permissions}
+
+Default RBAC policies grant scoped permissions to control-plane components, nodes,
+and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
+(beyond discovery permissions given to all authenticated users).
+
+This allows you to grant particular roles to particular ServiceAccounts as needed.
+Fine-grained role bindings provide greater security, but require more effort to administrate.
+Broader grants can give unnecessary (and potentially escalating) API access to
+ServiceAccounts, but are easier to administrate.
+
+In order from most secure to least secure, the approaches are:
+
+1. Grant a role to an application-specific service account (best practice)
+
+ This requires the application to specify a `serviceAccountName` in its pod spec,
+ and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).
+
+ For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
+
+ ```shell
+ kubectl create rolebinding my-sa-view \
+ --clusterrole=view \
+ --serviceaccount=my-namespace:my-sa \
+ --namespace=my-namespace
+ ```
+
+2. Grant a role to the "default" service account in a namespace
+
+ If an application does not specify a `serviceAccountName`, it uses the "default" service account.
+
+ {{< note >}}
+ Permissions given to the "default" service account are available to any pod
+ in the namespace that does not specify a `serviceAccountName`.
+ {{< /note >}}
+
+ For example, grant read-only permission within "my-namespace" to the "default" service account:
+
+ ```shell
+ kubectl create rolebinding default-view \
+ --clusterrole=view \
+ --serviceaccount=my-namespace:default \
+ --namespace=my-namespace
+ ```
+
+ Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
+ "default" service account in the `kube-system` namespace.
+ To allow those add-ons to run with super-user access, grant cluster-admin
+ permissions to the "default" service account in the `kube-system` namespace.
+
+ {{< caution >}}
+ Enabling this means the `kube-system` namespace contains Secrets
+ that grant super-user access to your cluster's API.
+ {{< /caution >}}
+
+ ```shell
+ kubectl create clusterrolebinding add-on-cluster-admin \
+ --clusterrole=cluster-admin \
+ --serviceaccount=kube-system:default
+ ```
+
+3. Grant a role to all service accounts in a namespace
+
+ If you want all applications in a namespace to have a role, no matter what service account they use,
+ you can grant a role to the service account group for that namespace.
+
+ For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
+
+ ```shell
+ kubectl create rolebinding serviceaccounts-view \
+ --clusterrole=view \
+ --group=system:serviceaccounts:my-namespace \
+ --namespace=my-namespace
+ ```
+
+4. Grant a limited role to all service accounts cluster-wide (discouraged)
+
+ If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
+
+ For example, grant read-only permission across all namespaces to all service accounts in the cluster:
+
+ ```shell
+ kubectl create clusterrolebinding serviceaccounts-view \
+ --clusterrole=view \
+ --group=system:serviceaccounts
+ ```
+
+5. Grant super-user access to all service accounts cluster-wide (strongly discouraged)
+
+ If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
+
+ {{< warning >}}
+ This allows any application full access to your cluster, and also grants
+ any user with read access to Secrets (or the ability to create any pod)
+ full access to your cluster.
+ {{< /warning >}}
+
+ ```shell
+ kubectl create clusterrolebinding serviceaccounts-cluster-admin \
+ --clusterrole=cluster-admin \
+ --group=system:serviceaccounts
+ ```
+
+## Upgrading from ABAC
+
+Clusters that originally ran older Kubernetes versions often used
+permissive ABAC policies, including granting full API access to all
+service accounts.
+
+Default RBAC policies grant scoped permissions to control-plane components, nodes,
+and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
+(beyond discovery permissions given to all authenticated users).
+
+While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions.
+Here are two approaches for managing this transition:
+
+### Parallel authorizers
+
+Run both the RBAC and ABAC authorizers, and specify a policy file that contains
+the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format):
+
+```
+--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json
+```
+
+To explain that first command line option in detail: if earlier authorizers, such as Node,
+deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC
+also denies that API request, the ABAC authorizer is then run. This means that any request
+allowed by *either* the RBAC or ABAC policies is allowed.
+
+When the kube-apiserver is run with a log level of 5 or higher for the RBAC component
+(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log
+(prefixed with `RBAC`).
+You can use that information to determine which roles need to be granted to which users, groups, or service accounts.
+
+Once you have [granted roles to service accounts](#service-account-permissions) and workloads
+are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer.
+
+### Permissive RBAC permissions
+
+You can replicate a permissive ABAC policy using RBAC role bindings.
+
+{{< warning >}}
+The following policy allows **ALL** service accounts to act as cluster administrators.
+Any application running in a container receives service account credentials automatically,
+and could perform any action against the API, including viewing secrets and modifying permissions.
+This is not a recommended policy.
+
+```shell
+kubectl create clusterrolebinding permissive-binding \
+ --clusterrole=cluster-admin \
+ --user=admin \
+ --user=kubelet \
+ --group=system:serviceaccounts
+```
+{{< /warning >}}
+
+After you have transitioned to use RBAC, you should adjust the access controls
+for your cluster to ensure that these meet your information security needs.
+
+{{% /capture %}}