Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to use Sidecar agents to strengthen Kubernetes security. Many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Introduction

Sidecar can help simplify application development, but each approach has its own security considerations.

Typical applications require common functions, such as logging, monitoring, tracking, configuration, and security. These functions can be implemented as part of the application code or run as separate processes outside the application code.

Each option has its advantages and disadvantages, but in modern cloud native approaches, the trend is to separate those common tasks from the core functional code of the application. The principle of this decoupling is to create consistency in common tasks in the application stack, which is critical in large distributed applications. It also eliminates the dependence on each language and the need to maintain proprietary libraries, thus making the choice of programming languages more flexible.

The container architecture designed for micro-services is maintained separately and written in different languages, so that developers do not have to rewrite similar development code to implement a single function.

For example, if the development team is writing a main application in Go and there are existing capabilities written in Python to collect logs and metrics, it is more efficient to unload Python code into Sidecar than to require the development team to rewrite it. The decoupling of common tasks from independent unified services deployed next to any core application service is called the "sidecar" architecture.

Side cars depend to a large extent on the main applications. The peripheral tasks attached to the sidecar cannot be implemented until they are attached to the main application, so for each instance of the application, the sidecar instance is deployed side by side with it. Each peripheral task loaded on the Sidecar is a separate function that can be added or removed independently, written and updated separately in any language, without affecting the main application code.

They run independently of the runtime and programming language, and can access the same resources as the main application. In a Kubernetes cluster, sidecar can be deployed as a Kubernetes DaemonSet or sidecar agent. Each of these options has its advantages and disadvantages.

Daemon assembly

The classic approach in Kubernetes is to use DaemonSet. DaemonSet is a copy of Pod and all nodes in the cluster are running on this Pod. When you create a container or container that contains shared features, such as logging metrics, performance, or configuration, it runs on each node in the cluster and provides these features to other containers that share that node.

In fact, for example, when collecting metrics, a DaemonSet Pod serves all Pod that share the same node, regardless of their type, function, and whether they are running replica sets or independent of each other.

Sidecar Agent

The Sidecar agent provides a more elaborate approach. The functions in the Sidecar agent provide micro-services separately in each Pod. The proxy container runs inside the Pod that contains the microservice and carries only the functionality required by the microservice, thus keeping the agent lightweight.

DaemonSet and Sidecar agents

Structural considerations: in an environment with highly separated glove boxes (for example, one container for logging, another container for measuring collection, and another container for performance), each pod must carry three sundries containers. This leads to inefficient resource utilization because most resources are performing the same common tasks rather than providing services to core applications. In this case, it is more efficient to use DaemonSet instead of multiple containers per pod.

Availability: deploying a new Sidecar container requires a restart of the entire Pod. There is no doubt that it is difficult to achieve this synchronization.

If the development cycle is out of sync, it can cause potential downtime when deploying a new DaemonSet or updating an existing DaemonSet.

Security of DaemonSets

Using DaemonSet, you can configure security settings at the container level, which contain details about privilege definitions, volume access rights, resource allocation, binary authorization, and anything related to container deployment.

However, in a DaemonSet environment, the container runs as a privileged container.

When a similar strategy is applied to multiple containers, it is a permanent risk for malicious actors to move horizontally between containers. It can not solve the network-based isolation and tunnel encryption for communication between nodes.

Security of Sidecar Agent

To protect the network layer, the sidecar agent is ideal. After uninstalling from the main application, they:

It is language-independent, so there is no need to adapt encryption to every language in the library.

Supports the creation of unified and / or target-specific policy and privileged access.

Manage tunnel encryption.

Manage internal cluster communications.

However, these agents do not have DaemonSet capabilities to monitor and verify container-level security settings.

Maximize container security

To take full advantage of the Sidecar agent and DaemonSet security features, you can use the Kubernetes native mechanism, called the admission controller. Using a dedicated admission controller in conjunction with the Sidecar agent, you can create an overall security suite that addresses all potential container threat options.

With Kubernetes, admission controller users can set fine-grained authorization for Pod creation and deployment. At the container level, you can use it to prevent the container from running as the root container, or to ensure that the root file system of the container is locked in read-only mode. It can restrict the extraction of images only from approved specific registries and reject unknown image registries.

Use Kubernetes admission controller and service grid controller

To enhance runtime security, a dedicated admission controller can be used to manage key security features, such as:

Binary authorization: a bottleneck in policy enforcement that limits deployment in your environment to signed and authorized images

Continuous vulnerability scanning: continuous scanning to check for vulnerabilities that exceed predefined thresholds before and after deployment

Configure the Pod security policy (PSP) in the Pod deployment settings

Manage Pod deployments using Selinux,Seccom and AppArmor

The next-generation Kubernetes workload protection solution starts upstream from the CI / CD pipeline to automatically identify legitimate workloads. The runtime policy ensures that only these workloads are deployed to the cluster.

In this way, application security can be simplified and accelerated by replacing multiple fragmented firewalls, security groups, and ACL with identity-based automated workload security separate from the network infrastructure.

After reading the above, do you have any further understanding of how to use Sidecar agents to enhance Kubernetes security? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.