Kubernetes (K8s) Service Account, Token, Secrets, Authentication and Authorization in RBAC Overview, #DevOps

In this blog, we will be covering Service Account, Token, Secrets & RBAC - Role-Based access control. It’s the way to outline which users can do what within a Kubernetes cluster. A Kubernetes cluster is a set of node machines for running containerized applications. 

This blog introduces the ServiceAccount object in Kubernetes, providing information about how service accounts work, use cases, limitations, alternatives, and links to resources for additional guidance.

Service Account

A service account provides an identity for processes that run in a Pod, and maps to a Service Account object. When you authenticate to the API server, you identify yourself as a particular user.

A service account is a type of non-human account that, in Kubernetes, provides a distinct identity in a Kubernetes cluster. Application Pods, system components, and entities inside and outside the cluster can use a specific ServiceAccount's credentials to identify as that ServiceAccount. This identity is useful in various situations, including authenticating to the API server or implementing identity-based security policies.

Default service accounts

When you create a cluster, Kubernetes automatically creates a ServiceAccount object named default for every namespace in your cluster. The default service accounts in each namespace get no permissions by default other than the default API discovery permissions that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. 

If you delete the default ServiceAccount object in a namespace, the control plane replaces it with a new one.  If you deploy a Pod in a namespace, and you don't manually assign a ServiceAccount to the Pod, Kubernetes assigns the default ServiceAccount for that namespace to the Pod.

Properties of Service Account: -

 Namespaced: Each service account is bound to a Kubernetes namespace. Every namespace gets a default ServiceAccount upon creation.

Lightweight: Service accounts exist in the cluster and are defined in the Kubernetes API. You can quickly create service accounts to enable specific tasks.

Portable: A configuration bundle for a complex containerized workload might include service account definitions for the system's components. The lightweight nature of service accounts and the namespaced identities make the configurations portable.

Service accounts are different from user accounts, which are authenticated human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque data. 

You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.

How to use service accounts?

To use a Kubernetes service account, we need to do the following:

1. Create a ServiceAccount object using a Kubernetes client like kubectl or a manifest          

2. Grant permissions to the ServiceAccount object using an authorization mechanism such as RBAC

3. Assign the ServiceAccount object to Pods during Pod creation.

Grant permissions to a ServiceAccount

You can use the built-in Kubernetes RBAC mechanism to grant the minimum permissions required by each service account. You create a role, which grants access, and then bind the role to your ServiceAccount. 

RBAC lets you define a minimum set of permissions so that the service account permissions follow the principle of least privilege.

 Secrets

A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don't need to include confidential data in your application code.

Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods.

Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. 

Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.

RBAC - Role-Based Access Control

In this blog, we will be covering RBAC or Role-Based access control.

It’s the way to outline which users can do what within a Kubernetes cluster. It’s an approach that’s used for proscribing access to users and applications on the system/network. RBAC could be a security style that restricts access to valuable resources based on the role the user holds, hence the name role-based.

Role-based access control (RBAC) is a technique of regulating access to a computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of a private user to perform a selected task, like read, create, or modify a file.

 Authentication and Authorization in RBAC

In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access).

Authentication

Once TLS is established, the HTTP request moves to the Authentication step.This is shown as step 1 in the diagram. The cluster creation script or cluster admin configures the API server to run one or additional Authenticator Modules. Authentication modules include Client Certificates, Password, and Plain Tokens, Bootstrap Tokens, and JWT Tokens (used for service accounts).

Users in Kubernetes

All Kubernetes clusters have 2 categories of users: service accounts managed by Kubernetes, and normal users. It is assumed that a cluster-independent service manages normal users in the following ways:

·        an administrator distributing private keys.
·        a user store like Keystone or Google Accounts.
·        a file with a list of usernames and passwords.

 Authorization

After the request is authenticated as coming from a selected user, the request should be authorized. This is shown as step 2 in the above diagram. A request should include the username of the requester, the requested action, and also the object affected by the action. The request is authorized if an existing policy declares that the user has permission to complete the requested action.