Basic concepts
All API objects k8s is saved in etcd in the operation of these API objects must be accessed through APIServer One important reason is that must be authorized to work by APIserver
Role: role, it is actually a set of rules that defines a set of operating authority Kubernetes API object
Role object specifies that it can have an effect Namepace is: mynamespace
Namespace is Kubernetes project in a logical management unit. Different Namespace API objects, when operated by kubectl command, are isolated from each other
Subject: the actors, both "human", can also be a "machine", it can also make "user" in your defined Kubernetes
RoleBinding: define "the role" and "role" binding relationship
Combined Role and binding
As long as the scope is RoleBinding just in the namespace definition RoleBinding in
as long as ClusterRoleBinding scope is the cluster-wide (all namespaces)
Role defines the next role just another name does not appear in this space and Role in the current namespace Role resides in
Role and expressed ClusterRoleBinding capable of operating in a namespace where the Role of the role of the entire cluster resources effectively in all namespaces Role upgraded to ClusterRole
ClusterRole represent the entire cluster simultaneously (each namespace) defined next role all namespaces have the same name as a Role
ClusterRole and RoleBinding only valid ClusterRole downgrade in the name of space RoleBinding for Role
Authorized User and the ServiceAccount
Kubernetes in the "User", that is "user" is just an authorization system of logical concepts, it needs such as Keystone, provided through external authentication service. Alternatively, you can also give APIServer specify a user name directly, the password file so Kubernetes authorization system, will be able to find the corresponding "user" from this document the Uer in k8s use less
Kubernetes also has the concept of "user group" (Group), which is a set of "user" means
Kubernetes responsible for the management of the "built-in user", it is generally used ServiceAccount ServiceAccount in k8s in place of User
serviceAccount sample process:
1. Create a resource ServiceAccount
2. Create a role resource
3. Create a rolebinding resource binding ServiceAccount and role (automatically generated corresponding Secret)
kubectl DESCRIBE Secret secretobject view the token information
k8s will automatically create an object when the Secret Role ServiceAccount and bundling
The Secret, is this ServiceAccount corresponding authorization document to interact with APIServer, we generally call it: the contents of the file are generally Token.Token certificate or password, which by way of a Secret objects stored in them this time Etcd users of Pod, you can use this statement ServiceAccount
If a Pod is not declared serviceAccountName, Kubernetes automatically created in its default Namespace named ServiceAccount default, and then assigned to the Pod. But in this case, the default ServiceAccount not associated with any Role. That is, At this point it has access to the vast majority of APIServer of course, this access needed Token, or default ServiceAccount corresponding object it provides Secret
In k8s most common is ServiceAccount, so Role + RoleBinding + distribution rights ServiceAccount it is time to prepare and install various plug-ins, often use this combination.