I've mentioned RBAC, authentication, authorization and the controls these implement earlier so I'm inclined to elaborate somewhat and shed some light on this topic. Fasten your seatbelts, because this might seem daunting at first, but we'll get there eventually.
First off, let's distinguish between public and private services - much like a shop where you are free to walk in versus, say, a private club where there's a bouncer at the door, allowing only patrons who are known members to enter. The site you're reading this article on might as well serve as an example of the former, since I never asked who you were - this content is not protected and requires no subscription, it's freely accessible. Otherwise you would have had to log in to prove your identity. (I don't currently produce subscription content.)
This maps to authentication and authorization - commonly abbreviated as "authn" and "authz" - which are distinct and indispensable parts of modern access control solutions. Authentication means identification: a service needs to know who you are. You'll provide some sort of identification and the system shall ascertain you are who you claim to be by verifying your credentials. Most access control systems, however, are more granular than that - not only do they want to know who is knocking on the door, they also need to be able to determine if that person can gain entry. Authorization means just that: the ability to tell whether a certain entity - be that a human user or a service account impersonated by software - is allowed to perform a specific action. This usually includes the actual subject of the activity as well, because most consumers shall be allowed to do certain things to a limited set of resources only. (Failure to authenticate will normally terminate a transaction, whereas omission thereof may result in classification of the request in question as "anonymous", provided the target doesn't require authentication. Please note some APIs may allow unauthenticated access to certain resources, but most will not because even seemingly unimportant and harmless pieces of information may lead to exploitation of known vulnerabilities and therefore disclosure always represents a security risk.)
That implies there needs to be a source - another register, if you will - of this as well, records to consult prior to granting or denying access. These may be provided by the same single facility or separate ones, internal or external, possibly involving federation to cater for the same need across multiple domains. Regardless of the providers, authentication and authorization are both essential to RBAC. This acronym stands for "role-based access control" and normally means the way to grant privileges to individuals in a granular albeit indirect manner - usually personal accounts are organized into groups, which receive privileges through roles assigned to them. Privileges facilitate access to features of a system and trickle down this structure to the individual making a request: from the role to the group and ultimately the principal representing the person accessing it. Nowadays there's a default denial in effect: while historically anything not explicitly denied was allowed, now anything not explicitly allowed is denied, reflecting the coerced paradigm shift in the world of information security. A principal may and probably shall be assigned multiple roles and sets of privileges derived from these are cumulative. (Practically we may have to perform multiple tasks and using the same account remains convenient as well as prudent in most cases.)
RBAC is widely employed as an approach and there are lots of implementations with a varying level of granularity and security - it's not the only such system, but it's a well-established one and while Kubernetes also supports alternatives, it's become the de facto standard by now, meaning it also no longer needs to be configured on the API server.
Your context will specify the principal you're submitting your requests as - some of this will be incorporated into the HTTP request by the client in the form of headers. You'll either be authenticated via mutual TLS, meaning you'll present a client certificate recognized by the server as one issued by a trusted certificate authority, or a token. (Authentication may be delegated to a provider outside your cluster, as is often the case.)
In Kubernetes, your principal shall be the subject to which a role is bound. Roles are sets of rules, denoting grouped API resources and verbs allowed for them in a specific namespace. Role bindings are responsible for associating these rules to subjects. If a role is bound to a subject, the subject is allowed to execute the verbs listed for the resources listed in the role. I typically draw figures of triangles with roles, role bindings and subjects as respective vertices and privileges in the surface area. Both Role and RoleBinding objects are namespaced, albeit cluster-wide (non-namespaced) variants of roles and bindings - aptly named ClusterRoles and ClusterRoleBindings - also exist. These may be used to grant privileges for an entire cluster or to re-use roles by defining them once as cluster roles and binding them in multiple namespaces with rolebindings as needed, thereby providing a scope. (One-way only, though: you can't "unscope" a role by binding it with a clusterrolebinding. These objects are mostly used in appropriately scoped pairs.)
Kubernetes employs AAA, or "triple-a", to protect cluster assets, which stands for authentication, authorization and admission control. The latter is an additional gating mechanism that is implemented by admission controllers running in the system. These are incorporated by the API, configurable, and can determine whether a request submitted by an already authenticated and authorized user can be considered valid. Requests passing validation by admission control are actually admitted - accepted - by the cluster and shall be processed - served and acted upon, that is. An admission controller may not only be "validating", but also a so-called "mutating" one, meaning it is able to alter a request mid-flight based on policies prior to admittance and persistence. Such controllers are capable of injecting mandatory settings, metadata or enforcing a baseline by changing values deemed inappropriate for the environment. The policies governing admission control may also be derived from various sources, often referred to as "policy engines".
What this boils down to could be summarized by a sequence of decisions like this: "Do I know you? Are you entitled to do this? Is the way you want to do it right?"
Stay tuned - we're still not through, but now there's at least light at the end of the tunnel.
