Basic Concepts of Kubernetes RBAC

Preface

When we use kind K8s to create various objects, the default user is the admin user, which has full permissions to manage the cluster.

In a real multi-user scenario, we cannot all use the admin user, and we need to assign appropriate permissions to different users according to the situation.

Authentication (K8s authentication)

Refers to whether the user can log in to k8s, that is, send a request to the K8s api-server

There are two types of users in the K8s cluster

• normal users: external users, not managed by K8s
• service accounts: managed by K8s

normal users

Normal users are independent of the K8s cluster and are maintained by external services. That is to say, normal users are not created within K8s, and there is no corresponding object within K8s.

External services can be

• an administrator (real person) who can distribute private keys
• A third-party vendor that provides user services, such as Google Accounts
• A simple list of saved usernames/passwords

The above paragraph may be difficult to understand. If a user does not exist inside K8s (K8s neither saves the username nor the password), how does K8s authenticate the user (Authentication)?

K8s has several methods to authenticate users. For the case of using kubectl to access K8s, K8 can use the certificate issued by its own CA (certificate authority) to authenticate users.

• Authentication user process of general application system: we provide user name and password, the application checks whether the user name and password exist and is valid in its own database, and if there is, it will pass user authentication
• The process of K8s for normal users who use Kubectl (certificate verification) to authenticate users is: Normal user (that is, kubectl) provides a certificate to K8s, K8s checks whether the certificate is valid, and if it is valid, it passes user authentication

Therefore, any user who can provide a valid certificate can pass K8s user authentication and send a request to K8s (of course, whether the request can be executed depends on whether there is permission, that is, Authorization)

After passing user authentication, K8s will use the CN in the certificate as the username (for example, if "/CN=tstest" in the certificate, the username is "tstest")

Organization acts as a group, and then the user's authority (Authorization) is determined by the user name and the Role bound to the group.

It can be seen that when we run the same kubectl command line with different accounts in the linux environment, kubectl sends the certificate configured in the ~/.kube/config file to K8s, and then K8s uses the CN of this certificate K8s doesn't care which Linux account runs the kubectl command

service accounts

Service accounts are managed by K8s and belong to a specified namespace. Service accounts can be created automatically by K8s or manually with the kubectl command.

Different from normal user, service accounts have corresponding K8s objects, and the password information related to service accounts will be stored in K8s as Secrets.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: eks-cluster-ssm
  namespace: interview-namespace
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::X:role/eks-cluster-ssm

These Secrets are mounted to the Pod when the Pod starts, so that processes in the Pod can send requests to the api-server on behalf of the service account.

normal users VS service accounts

The difference between Normal users and service accounts is mainly reflected in the following points
1.Users are for people, while service accounts are for processes in Pods
2. The names of Users are unique within the K8s cluster, and service accounts are built in namespaces, so the names of service accounts in different namespaces can be the same
3. As mentioned above, Users are external and do not belong to K8s management, so Users generally exist in the database or Idp outside the K8s cluster. Inside K8s, these users have only one name and role bound to provide the permissions required by Users
4. There will be a service account in each namespace, either created manually, or the default ServiceAccount "default", which is used by Pods in this namespace. By authorizing service accounts, the Pods in this namespace have permission to call K8s resources

Api Request Category

When we use the kubectl command, we actually send a request to the api-server (request)

Api request is divided into the following three types

1. Requests sent by normal user: For example, use the kubectl command to create a Pod
2. The request sent by the service account: For example, a Pod requests to access the Secret that stores the password of the mirror warehouse, and the request is sent by the associated service account in the Pod
3. anonymous request: all requests except the above two requests

It can be seen that in addition to using kubectl to send requests to api-server from outside the k8s cluster, K8s also sends requests to api-server, and all requests must be authenticated first.

Authentication strategy

K8s has the following authentication methods
1.client certificates
2.bearer tokens
3.authenticating proxy
4. HTTP basic authentication mechanism through authentication plugin

When an http request is sent to api-server, k8s will associate the following information from the request

• Username: A string of characters representing the end user, such as kube-admin or tstest@elephdev.com
• UID: a string of unique characters representing a user
• Groups: represents a logically related group of users, such as system:masters or devops-team
• Extra fields: other information that may be required for authentication

It should be noted that when multiple authentication methods are enabled at the same time, the first authentication method is successfully authenticated, that is, the authentication is passed, other methods are no longer authenticated, and the api-server does not guarantee the order of the authentication methods.

All successfully authenticated users will be added to the group "system:authenticated".

client certificates

When we use client certificates for authentication, we need to provide K8s with a valid certificate.

This certificate can be provided externally, or it can be approved by K8s itself

If it is provided externally, we need to use the --client-ca-file=SOMEFILE parameter to introduce information such as the CA of the external certificate when starting api-server to verify the validity of the certificate uploaded by the client.

When the client uploads the validity of the certificate, K8s will use the Subject CN of the certificate as the username and Organization as the Group

bearer tokens

Bearer tokens are simply understood as a string of characters.

When the client sends an http request to the server, it puts bearer tokens in the request header "Authorization", and the server determines whether the request is valid by verifying the validity of the bearer tokens.

There are several ways to use bearer tokens in K8s, we only briefly describe three of them here
1.Static Token File

api-server obtains a list of valid Tokens and corresponding users and groups from an external file (csv) through the --token-auth-file=SOMEFILE parameter

When the client sends a request, api-server compares the bearer tokens in the request header with the token in the file to determine whether the request is valid

2. Service Account Tokens
   When a Service Account is created manually or automatically, Service Account Tokens are automatically created and stored in the corresponding namespace as a K8s object "serect"

As mentioned above, Service Account mainly provides the function of accessing api-server for Pods, so after Service Account Tokens are created, they will be automatically mounted in related Pods, so that Pods can use this Service Account Tokens to send requests to api-server

In addition to being used on Pods, it can also be used for requests outside K8s

Run the following command to get the secret token (Service Account Tokens)

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-cluster-ssm | awk '{print $1}')

If you have a Service Account to access Dashboard, you can log in directly with TOKEN

This is actually a practical example of using Service Account Tokens to access api-server outside K8s

3. OpenID Connect Tokens

K8s can use the ID Token in the OAuth2 token response as the bearer token for authentication access

This makes it possible to manage external users of K8s using a third-party Idp that supports OpenID

The main difference when using OpenID Connect Tokens is - the user first needs to log in to the Idp and get the ID Token from the Idp as a bearer token

K8s Authorization (authorization)

1. Authorization process

The request sent to K8s first goes through Authentication and then enters the Authorization stage.

In the authorization phase, K8s will check whether the request has permission to access the required resources. If it has permission, it will start to execute the request. If it has no permission, it will report an error and return.

Through Api-server, K8s uses the accompanying information in the request (including the Username, UID, Group, etc. mentioned above) to authorize the request (the specific authorization control is performed by the corresponding Admission Controllers).

Api-server will look up all policies to check whether there is a policy that allows the action in the request, if it exists, the request is allowed to execute, otherwise it will refuse to execute and return 403 Error.

When multiple authorization modules are configured, requests pass through each module's checks in order. If any module allows or denies the request, this is the final authorization result, and other authorization modules do not continue to check authorization.

K8s will check the following information in the request when authorizing, some of the information is the same as that used for authentication

• user: same as the information checked in authentication
• group: same as the information checked in authentication
• extra: same as the information checked in authentication
• API: Whether it is an Api resource
• Request path: non-resource (API resource) endpoint, such as /healthz
• API request verb: API actions, such as get, list, create, update, patch, specific actions on a resource, such as listing all pods
• HTTP request verb: used for HTTP actions in non-resource requests, such as get, post, put
• Resource: The name or ID of the resource requested to be accessed
• Subresource: The name or ID of the subresource requesting access
• Namespace: The namespace where the resource is located
• API group: API group requesting access, API group refers to a group of * APIs that control related resources, if not specified, it represents core API group

2. Authorization module

K8s api-server has the following authorization modules

1. Node: A special authorization module that authorizes kubelets based on the Pod running on the node
   2.ABAC: Attribute-Based Access Control
2. RABC: Role-Based Access Control
3. Webhook: HTTP request callback, through a web application to return whether there is permission to perform an operation

RBAC authorization

Role-based access control (RBAC) controls user permissions through user-bound roles

RBAC has four kinds of K8s objects
1.Role: Set specific permissions for K8s resource access, associated with a namesapce
2.ClusterRole: Similar to Role, the difference is that it is not associated with a namepsace, for the entire Cluster
3.RoleBinding: Bind the user to the Role so that the user can obtain specific permissions
4.ClusterRoleBinding: Similar to RoleBinding, the difference is that it is not associated with a namepsace

ClusterRole has several uses

1. Define permissions on objects in a namespace, and then authorize users in other namespaces
2. Define permissions on objects in a namespace, and then authorize users in all namespaces
3. Define permissions on cluster-scoped objects

Example: Created serviceaccount admin-user for logging into Dashboard and bound Clusterrole cluster-admin

This ClusterRole provides the ServiceAccount with full access to the Cluster

apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kube-system

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin-user
namespace: kube-system

Summarize

There are two types of K8s users

1. Internal users (service accounts) mainly provide pods with access to api-server services, with corresponding K8 objects, and of course they can also be accessed from the outside using their tokens
2. External normal users are managed by third-party services outside K8s, and there is no corresponding K8s object

K8s is authenticated through certificates, bearer tokens, etc., but not through general user/password authentication.

There are several ways to authorize K8s. For the RBAC method, it is user, role, and role binding. The three elements are combined for authorization.