Kubernetes

Security in Kubernetes: authentication, authorization, and securing sensitive data

Introduction

• An automated method for managing, scaling, and deploying containerized applications is called Kubernetes, and it is free to use. Applications in a distributed environment are deployed and managed using it. The integrity and confidentiality of the data stored in the cluster are ensured by security, which is a crucial consideration when working with Kubernetes. We will talk about the various security features of Kubernetes in this post, such as authentication, authorisation, and protecting sensitive data.
• It could appear difficult to secure Kubernetes. Kubernetes cannot be secured by simply turning on a security module or installing a security tool since it is an extremely complicated system made up of numerous different components.Instead, Kubernetes security mandates that teams handle every security risk type that could have an impact on the various layers and services within a Kubernetes cluster. Teams must be aware of how to secure Kubernetes nodes, networks, pods, data, etc.
  Kubernetes administrators should also be aware of the security tools that Kubernetes comes with out of the box and the several third-party security technologies that may be integrated with clusters to fill in the gaps. The fact that Kubernetes has some native security features, such Role-Based Access Control, even though it isn’t a security platform, makes this a tricky problem (RBAC).
• Considering the kinds of vulnerabilities that each component of the Kubernetes stack is susceptible to, then identifying the tools and resources available to help secure them, may be the simplest way to approach Kubernetes security.

Authentication

• Verifying a user’s or a process’s identity when they want to access a system is known as authentication. Authentication in Kubernetes is used to identify and grant access to individuals and processes. You can use a variety of authentication methods, including passwords, certificates, and tokens. It’s crucial to make sure that the cluster can only be accessed by processes and users that have provided valid credentials. Additionally, employing multi-factor authentication and creating strong passwords are two additional recommended practices that ought to be followed while configuring authentication in Kubernetes.
• The complete HTTP request is the input to the authentication phase, but it usually looks at the headers and/or client certificate.
• Client certificates, passwords, simple tokens, bootstrap tokens, and JSON Web Tokens are just a few of the authentication modules available (used for service accounts).
• It is possible to specify multiple authentication modules, in which case each one is tested one at a time until one of them is successful.
• The request is declined with HTTP status code 401 if it cannot be authenticated. In every other case, the user is verified as a certain username, and the username is made available to later phases for use in their judgments. In contrast to other authenticators, some also provide the user’s group affiliations.
• Despite the fact that Kubernetes employs usernames for access control and request logging, it lacks a User object and does not save usernames or other user-related data in its API.

Authorization
According to a user’s identification and privileges, authorization is the process of allowing access to resources. Based on the user’s identification and privileges, Kubernetes uses authorization to allow access to resources. Role-based access control is one example of a sort of authorization that can be employed (RBAC). It’s crucial to guarantee that only authorized users can access the cluster’s resources. Furthermore, there are a few best practices that ought to be adhered to when configuring authorization in Kubernetes, like establishing least-privilege access and routinely auditing access rights.

A request must contain the requester’s username, the requested action, and the item it will affect. If an existing policy states that the user has authorization to carry out the requested action, the request is considered to be permitted.

Azma, for instance, can only access pods in the namespace projectCaribou if he has the policy listed below.

{
 "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
 "kind": "Policy",
 "spec": {
 "user": "azma",
 "namespace": "projectCaribou",
 "resource": "pods",
 "readonly": true
 }
}

If Azma makes the following request, the request is authorized because he is allowed to read objects in the projectCaribou namespace:

{
 "apiVersion": "authorization.k8s.io/v1beta1",
 "kind": "SubjectAccessReview",
 "spec": {
 "resourceAttributes": {
 "namespace": "projectCaribou",
 "verb": "get",
 "group": "unicorn.example.org",
 "resource": "pods"
 }
 }
}

Azma’s request is turned down if he attempts to write (create or update) to any of the objects in the projectCaribou namespace. If Bob attempts to read (get) an object from a namespace other than his own, such as "projectFish," his request is rejected.

For interaction with pre-existing enterprise- or cloud-provider-wide access control systems, Kubernetes authorization necessitates the use of standard REST characteristics. The Kubernetes API may not be the only API that these control systems interface with; hence, it is crucial to adopt REST formatting.

Kubernetes API Security
Client libraries, REST requests, kubectl, and other user interfaces allow users to access the Kubernetes API. An API access authorization can be granted to both human users and Kubernetes service accounts. The following diagram shows the several steps that a request must take before it can be processed by the API:

Transport security

The first network interface other than localhost is where the Kubernetes API server by default listens, using TLS security on port 6443. The API runs on port 443 in a typical Kubernetes production cluster. The port can be changed with the --secure-port flag, and the listening IP address can be set with the bind-address flag.

A certificate is displayed by the API server. This certificate may be signed by a private certificate authority (CA) or based on a public key infrastructure connected to an officially recognized CA. The certificate and corresponding private key can be set by using the tls-cert-file and tls-private-key-file flags.

If your cluster uses a private certificate authority, you need a copy of that CA certificate configured into your /.kube/config on the client so that you can trust the connection and be confident it was not intercepted.

Securing Sensitive Data
Any information that must be shielded from unauthorized access or disclosure qualifies as sensitive data. Sensitive data can be protected in Kubernetes in a variety of ways, including access control and encryption. Sensitive data can be protected using a variety of security mechanisms, such as access restriction and encryption. Making sure that only authorized individuals may access the sensitive data in the cluster is crucial. Additionally, there are specific best practices that must be adhered to while protecting sensitive data in Kubernetes, including the use of powerful encryption methods and routine access authorization auditing.

Conclusion
This blog post covered Kubernetes security and how apps can be shielded from unauthorized access or disclosure using it. We talked about recommended practices for each of the topics we covered: Kubernetes authentication, authorization, and safeguarding sensitive data. It’s crucial to stick to these recommendations and routinely evaluate your security settings to make sure your Kubernetes cluster is secure.