Explain how Role-Based Access Control (RBAC) is implemented in Kubernetes and provide an example of creating a Role and RoleBinding.

Role-Based Access Control (RBAC) is a security mechanism in Kubernetes that controls who can access the Kubernetes API and what operations they are allowed to perform. It authorizes API requests based on the roles assigned to users, groups, or service accounts. RBAC provides granular control over cluster resources, enabling you to implement the principle of least privilege and enhance the security of your Kubernetes environment. RBAC in Kubernetes is implemented using the following core resources: Roles: A Role defines a set of permissions within a specific namespace. Permissions are purely additive (there is no "deny" rule). A Role specifies which resources are allowed to be accessed and the verbs (actions) that are allowed to be performed on those resources. For example, a Role might allow reading Pods and Deployments within a specific namespace. ClusterRoles: A ClusterRole is similar to a Role, but it is cluster-scoped, meaning that it applies to the entire cluster. ClusterRoles can be used to grant access to cluster-wide resources, such as Nodes, or to grant permissions across all namespaces. RoleBindings: A RoleBinding grants the permissions defined in a Role to a specific user, group, or service account within a specific namespace. It binds a Role to a subject (the user, group, or service account). ClusterRoleBindings: A ClusterRoleBinding is similar to a RoleBinding, but it is cluster-scoped, meaning that it grants the permissions defined in a ClusterRole to a subject across the entire cluster. Subjects: Subjects are the entities that are granted permissions. Subjects can be users, groups, or service accounts. Verbs: Verbs are the actions that are allowed to be performed on resources. Common verbs include get, list, watch, create, update, patch, and delete. Resources: Resources are the Kubernetes objects th....