Detailed Overview of Kubernetes Security Primitives

Introduction

In this blog, we are going to discuss the Security of the Kubernetes cluster.

Due to the dispersed, dynamic nature of a Kubernetes cluster, Kubernetes security is crucial throughout the container’s lifetime. For each of the three stages of an application’s lifecycle—build, deploy, and runtime—different security strategies are needed. Kubernetes has built-in benefits for security.

Attackers who get unauthorized access to the kubelet have access to the APIs, which puts node or cluster security at risk.

Action needed to prevent the Kubernetes Cluster's Security Breach

1. Limiting who has access to the Kubernetes API.
2. Regulating kubelet access
3. Adjusting a workload’s or user’s capabilities in real-time
4. Preventing breaches of cluster components

1: Limiting who has access to the Kubernetes API

1. For all API communication, use Transport Layer Security (TLS)
2. Authentication using API
3. Authorization for API

1. For all API communication, use Transport Layer Security (TLS)

• Most installation techniques will enable the creation of the required certificates and their distribution to the cluster components.
• Kubernetes expects that all API communication in the cluster is encrypted by default with TLS.
• Administrators should become familiar with each component’s settings to spot potentially insecure communications.
• due to the possibility of some components and installation processes enabling local ports through HTTP.

2. Authentication using API

• When installing a cluster, pick an authentication method that corresponds to the usual access patterns for the API servers.
• Even clients that are a part of the infrastructure, such as nodes, proxies, the scheduler, and volume plugins, all API clients require authentication.
• These clients are normally service accounts or employ x509 client certificates, and they are either set up as part of the cluster installation or established automatically during cluster starts.

3. Authorization for API

• Each API call must successfully pass an authorization check after it has been authenticated.
• A built-in Role-Based Access Control (RBAC) component that comes with Kubernetes matches an incoming user or group to a set of permissions contained in roles.
• It is advised that you combine the NodeRestriction admission plugin with the Node and RBAC authorizers.
• For smaller clusters, basic and broad roles could be appropriate.
• however, when more users engage with the cluster it might be required to divide teams into separate namespaces with more restrictive roles.
• more restricted responsibilities need to be carefully examined to avoid unintentional escalation. If the roles that come out of the box don’t work for your use case, you can create your own.

2: Regulating kubelet access

• Kubelets expose HTTPS endpoints that give nodes and containers powerful control. Kubelets by default permit unauthorized access to this API.
• Production clusters must have authentication and permission for Kubelet enabled.

3: Adjusting a Workload's or user's Capabilities in Real-Time

There are stronger restrictions available as rules to restrict how those objects interact with the cluster, themselves, and other resources according to use cases.

1. Limiting resource usage on a cluster

• The quantity or capacity of resources allotted to a namespace is constrained by a resource quota.
• It is most frequently used to restrict the amount of CPU, RAM, or persistent disc that a namespace can allocate.
• To prevent users from demanding unreasonably high or low values for often reserved resources like RAM, limit ranges restrict the maximum or minimum size of certain of the aforementioned resources. They also serve as default limits when no limits are defined.

2. Controlling what privileges containers run with

• You can set up Pod security admission to enforce a specific Pod Security Standard inside a namespace or to monitor for violations.

3. Preventing containers from loading unwanted kernel

• When a piece of hardware is connected or a filesystem is mounted, the Linux kernel automatically loads kernel modules from the disc if they are required. Even unprivileged processes can make some kernel modules related to network protocols load simply by creating a socket of the right type, which is especially relevant to Kubernetes. As a result, a security flaw in a kernel module that the administrator believed to be inactive may be exploited by an attacker.
• You can remove certain modules from the node or create rules to prevent them from loading automatically.

4. Restricting network access

• Using a namespace’s network policies, application writers can limit which pods from other namespaces are allowed to access ports and pods inside of their namespace.

5. Restricting cloud metadata API access

• Limit the rights granted to instance credentials when operating Kubernetes on a cloud platform, utilize network policies to limit pod access to the metadata API, and stay away from utilizing provisioning data to send secrets.

6. Controlling which nodes pods may access

• There are no limitations on which nodes can run a pod by default.
• End users have access to a wide range of rules that Kubernetes provides to regulate the deployment of pods into nodes as well as taint-based pod placement and eviction.
• As an administrator, a beta admission plugin Pod NodeSelector can be used to force pods within a namespace to default or require a specific node selector, and if end users cannot alter namespaces, this can strongly limit the placement of all of the pods in a specific workload

4: Preventing Breaches of Cluster Components

1. Restrict access to etcd

• The etcd servers should always be isolated behind a firewall that only the API servers may access, and administrators should always utilize strong credentials from the API servers to their etcd server, such as mutual auth using TLS client certificates.

2. Enable audit logging

• An experimental feature is known as the audit logger logs API actions for later review in the case of a hack. Enabling audit logging and storing the audit file on a secure server are both advised.

3. Restrict access to alpha or beta features

• Beta and alpha Kubernetes features are still under development and could include flaws or restrictions that lead to security concerns. Always weigh the potential benefits of an alpha or beta feature against any security risks. Disable features you don’t utilize when in doubt.

4. Rotate infrastructure credentials frequently

• It becomes more difficult for an attacker to use a secret or credential the shorter its lifespan. Automate the rotation of certificates and give them a short lifespan.
• Employ a source of authentication that can regulate the duration of issued tokens, and whenever possible, use short lifetimes. Consider rotating service-account tokens often if you utilize them in external integrations.
• A bootstrap token used to create nodes should have its permission removed once the bootstrap phase is finished.

5. Review third-party integrations before enabling them

• Numerous third-party Kubernetes integrations could change the cluster’s security profile. Always check the permissions that an extension seeks before providing it access when enabling an integration.
• For example, many security integrations may request access to view all secrets on your cluster which is effectively making that component a cluster admin. When in doubt, restrict the integration to functioning in a single namespace if possible.

6. Encrypt secrets at rest

• Any information accessed through the Kubernetes API will often be stored in the etcd database, which might give an attacker extensive insight into the state of your cluster.
• Always use a reputable backup and encryption solution to encrypt your backups, and whenever it’s practical, think about employing whole disc encryption.

Conclusion

Due to the wide range of dangers facing clusters and pods, including malicious actors, malware operating inside containers, broken container images, and compromised or rogue users, Kubernetes security is crucial.

Without adequate safeguards, a hostile actor that compromises an application might try to take over the host or the cluster as a whole.

About CloudThat

CloudThat is also the official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft gold partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best in industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

Drop a query if you have any questions regarding Kubernetes and I will get back to you quickly.

To get started, go through our Consultancy page and Managed Services Package that is CloudThat’s offerings.