Shulou(Shulou.com)05/31 Report--

This article to share with you is about the protection of cloud native application of the three K8S native controls are what, Xiaobian think quite practical, so share to everyone to learn, I hope you can read this article after some harvest, not much to say, follow Xiaobian to see it.

As more and more enterprises adopt container technology, they are facing a major challenge-how do you secure container applications? Security is often more of a backlog issue than storage, networking, and monitoring. Add to that the need for Kubernetes-related training for employees, and the focus on safety has lagged far behind. In fact, a survey published by The New Stack showed that nearly 50% of Kubernetes users said security was their top unsolved problem.

We'll dive into the security threats Kubernetes faces and demonstrate best practices for securing clusters, then provide some useful tools to help developers maintain cluster security.

tool describes

Rancher Kubernetes Engine(RKE)

RKE is a CNCF-certified Kubernetes distribution that runs fully within Docker containers. It addresses the complexity of Kubernetes installations by removing most of the host dependencies and providing a stable path for deployment, upgrade, and rollback. RKE uses declarative YAML files to configure and create Kubernetes environments. This enables reproducible local or remote environments.

KubeLinter

KubeLinter is a static analysis tool that looks at Kubernetes YAML files to ensure that declared application configurations adhere to best practices. KubeLinter is StackRox's first open source tool for implementing security checks from the command line and as part of the CI process. KubeLinter is a binary file that takes paths to YAML files and performs a series of checks on them. Administrators and developers can create their own policies to enforce, resulting in faster, more automated deployments.

StackRox

StackRox Kubernetes Security Platform protects critical applications by building, deploying, and running them. StackRox is deployed in your infrastructure and integrated with your DevOps tools and workflows to provide frictionless security and compliance. StackRox Policy Engine contains hundreds of built-in controls to enforce configuration management for DevOps and security best practices, CIS benchmarks, and NIST runtime security for containers and Kubernetes. StackRox profiles your workload, enabling you to make informed decisions about the security of your workload.

used in combination

RKE, KubeLinter, and StackRox enable you to deploy reproducible security clusters, visualize profiles, and access security vulnerabilities, and create declarative security policies. Next, let's talk about how these apps work together to address security threats.

Assessing security risks

Let's first look at Kubernetes 'attack vectors. Microsoft recently released a Kubernetes attack matrix based on MITRE ATT&CK framework:

https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

The framework is adapted for Kubernetes and is based on real-world observations and cases. Fortunately, there are strategies that mitigate all the different problems. First, we can start by hardening our Kubernetes control plane. After that, we'll shift our focus to securing the container workloads we run.

Control plane Hardening

The Kubernetes control plane consists of the following components:

Kubernetes API Server

kube-scheduler

kube-controller-manager

etcd (if applicable)

cloud-controller-manager (if applicable)

Etcd will likely be on the control plane node, but it can also provide a remote environment for high availability use cases. Cloud-controller-manager is also installed in the provider instance.

Kubernetes API Server

Kubernetes REST API server is the core component of control-plane. This server handles calls to the REST API that contain all communication between different components and users. This dependency makes securing API Server a top concern. In previous versions of K8S, certain vulnerabilities could be fixed by upgrading to newer versions. However, you can also control the following hardening tasks:

Enable Role Based Access Control (RBAC)

Ensure all API traffic is TLS encrypted

Enable Audit Log

Set authentication for all K8S API clients

Cluster in this declarative format can be easily set up with development tools such as RKE. The following is a default RKE config.yml.file snippet. As you can see, we were able to enable audit logs, TLS (between Kubernetes components), and RBAC by default.

1. kube-api: 2. image: "" 3. extra_args: {} 4. extra_binds: [] 5. extra_env: [] 6. win_extra_args: {} 7. win_extra_binds: [] 8. win_extra_env: [] 9. service_cluster_ip_range: 10.43.0.0/16 10. service_node_port_range: "" 11. pod_security_policy: false 12. always_pull_images: false 13. secrets_encryption_config: null 14. audit_log: null 15. admission_configuration: null 16. event_rate_limit: null 17.… 18. authentication: 19. strategy: x509 20. sans: [] 21. webhook: null 22.… 23. authorization: 24. mode: rbac 25. options: {}

Setting up authentication for all K8S API clients is the current challenge. We need to apply a zero-trust model to the workloads running in our cluster.

kube-scheduler

Kubernetes default scheduler is pluggable. So you can build your scheduler or set up multiple schedulers for different workloads. Either way, security needs to be guaranteed. These tasks ensure it is safe:

Set up a secure port to communicate with API Server

Ensure scheduler runs with minimum required privileges (RBAC)

Restrict file permissions for kube-scheduler pod specifications and kubeconfig files

With RKE, we can guarantee its connection to the API server by verifying the default scheduler address (set to 127.0.0.1). Additionally, file permissions are restricted by ensuring that the root user owns the scheduler YAML file.

stat -c %U:%G /etc/kubernetes/manifests/kube-scheduler.yaml

kube-controller-manager

The Kubernetes system regulator, or kube-controller-manager, is a daemon that regulates the system using a kernel control loop. To secure the controller, you need to adopt a strategy similar to scheduler:

Set up a secure port to communicate with API Server

Ensure scheduler is running with minimum required privileges (RBAC)

Restrict file permissions for kube-controller-manager pod specifications and kubeconfig files

As with schedulers, we can ensure that communication uses local addresses (rather than insecure loopback interfaces) and that the root user owns the controller YAML file.

stat -c %U:%G /etc/kubernetes/manifests/kube-controller-manager.yaml

etcd

The last core component of the control plane is its key-value store, etcd. All Kubernetes objects are located in etcd, which means all your configuration files and keys are stored here. A best practice is to use a separate key management solution, such as Hashicorp Vault or a cloud provider's key management service, to encrypt keys or manage key information. When you manage your database, you need to keep in mind the following key factors:

Restrict read/write access to the database

encryption

We want to restrict any updates or changes to manifest to services that are allowed access. Using RBAC controls in conjunction with a zero-trust model will help you get started. Finally, using etcd encryption can be cumbersome. Based on this, Rancher has a unique method of producing keys in the initial cluster configuration. Kubernetes has a similar policy, although files with keys also need to be secure. Your organization's security requirements will determine where you are and how you protect sensitive information.

Cloud-controller-manager

Cloud cloud-controller-manager is unique to cloud providers, and it is unique to distributions that require clusters to communicate with provider APIs. When used with a cloud provider, administrators will not be able to access the master node of their cluster, so they will not be able to run the hardening steps mentioned earlier.

Secure workloads with Kubernetes native controls

Now that our control plane is secure, it's time to take a look at our applications running in Kubernetes. Similar to the previous section, let's break security down into the following parts:

Container Mirrors Security

runtime

persistence

network

Role Based Access Control (RBAC)

In the following sections, we will delve into the various considerations for each section.

Container Mirrors Security

Managing containers before they are used is the first obstacle to container adoption. First, we need to consider:

Basic Mirror Selection

update frequency

Non-essential software

Accessible build/CI tools

The most important thing is to choose a safe base image, limit unnecessary packages and secure the image repository. Most mirror repositories now have built-in mirror scanning tools that make it easy to secure. StackRox Kubernetes security platform can automatically execute images that can be used to boot containers and identify security issues, including vulnerabilities and problematic packages, in an image layer separate from the underlying operating system (OS) image.

If you want to know more, you can visit the following link to view related articles:

https://www.stackrox.com/post/2020/04/container-image-security-beyond-vulnerability-scanning/

Runtime

Runtime security spans different Kubernetes capabilities, and the core goal is to ensure that our workloads are secure. Pod security policies have the following capabilities to protect container security:

Linux Features

SELinux context for container

Host network and port usage

Use of host file systems

User and groupID of container

Keep in mind the zero-trust approach applied to the system, where functionality should be set up so that the container has the minimum functionality required to function at runtime. For better visualization, StackRox's risk profile automatically identifies which containers contain tools useful to attackers, including bash. It also alerts you to suspicious tool usage and monitors, detects, and alerts you about runtime activity, such as executing unusual or unexpected processes within the container.

persistence

Running stateful workloads in Kubernetes creates a backdoor into your container. By attaching storage and possibly providing executable files or information to containers that should not be accessed, the likelihood of an attack is greatly increased. Kubernetes best practices ensure that stateful workloads run with the minimum privileges required. Other considerations include:

Use namespaces as natural boundaries for storage

No privileged containers

Restrict Pod volume access using Pod security policies

StackRox helps mitigate these threats by providing dynamic policy-driven admission controls as part of the StackRox platform. This enables enterprises to automatically enforce security policies, including restrictions on host mounts and their writability before deploying containers to Kubernetes clusters.

network access

Network access is a tough challenge in Kubernetes due to the lack of visibility into containers. By default, network policies are disabled and each pod can reach other pods on the Kubernetes network. Without this default, it would be difficult for newcomers to learn. As businesses mature, we should strive to lock in all traffic except what we deem necessary. This can be done using network policies configured by namespaces, but it is also important to note the following:

Use namespaces as natural boundaries for network policies

Enable default Deny policy in each namespace

Use network policies specific to the traffic required for each pod

One of the major challenges of network strategy is visualization. StackRox helps prevent network mapping by monitoring active network traffic between pods and automatically generating and configuring network policies that restrict traffic to the extent required for application components to function.

Role Based Access Control (RBAC)

RBAC is at the heart of cluster security. RBAC permissions for Kubernetes are additive, so the only vulnerability to RBAC is exploitable permissions granted by administrators or users. The most common problem we encounter is that users have cluster administrator privileges when they shouldn't. Fortunately, there are a number of RBAC best practices that can help reduce this type of problem:

Use different service accounts for different types of workloads and apply the principle of least privilege.

Periodically review your cluster's RBAC configuration.

Use different service accounts for different types of workloads and apply the principle of least privilege.

Avoid overuse by cluster administrators

RKE clusters use RBAC as the default authentication option when clustering. StackRox extends this default option by helping enterprises restrict Kubernetes RBAC permissions according to the least privilege principle. We monitor user and service accounts for cluster RBAC settings and identify accounts with excessive permissions on the cluster.

The above is what the three K8S native controls that protect cloud native applications are. Xiaobian believes that some knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.