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

This article focuses on "what are the suggestions for deploying a secure kubernetes application". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what are the suggestions for deploying a secure kubernetes application?"

Kubernetes provides many rules that can effectively improve the security of your application. Configuring these rules requires you to be proficient in kubernetes and be clear about the security requirements for deployment. The best practices we highlight here refer to the lifecycle management of containers: build, package, and run, and specifically refer to the deployment of kubernetes.

Make sure there are no vulnerabilities in the image

Running the container with a flawed image puts your environment at risk of being more vulnerable. Making sure that all your software is free of known vulnerabilities can reduce a lot of attacks.

Conduct continuous security vulnerability scanning-containers may contain expired packages that carry known vulnerabilities. Vulnerability scanning cannot be an one-off process, because new vulnerabilities are released every day. A process of continuously evaluating the security of images is critical to ensuring a necessary security situation.

Make regular security updates to the environment-once a loophole is found in the running container, you must update the source mirror and redeploy the container. Try to avoid updating running containers directly (such as using apt-update), as this can break the relationship between the image and the container. Upgrading the container using kubernetes's rolling update feature is fairly simple, allowing you to update running applications step by step and mirror them to the latest version.

Ensure that only authorized images are used in the environment

If you cannot ensure that only mirrors with organizational policies are allowed to run, the organization runs the risk of running vulnerable or even malicious containers. It is dangerous to download and run an image from an unknown source. This is equivalent to running software provided by an unknown vendor on a production environment server. Please don't do this.

Use private repositories to store your authenticated images and make sure that only authenticated images are uploaded to these private repositories. This one alone has narrowed it down from thousands of publicly available images to only a few potential images that can enter your assembly line. Build a CI pipeline to integrate security assessments (such as vulnerability scanning) and make it part of the build process.

The CI pipeline must ensure that only reviewed code (allowed on the production environment) can be used to build images. Once the image is built, it must scan for security vulnerabilities, and only if no problems are found can the image be uploaded to the private repository and deployed to the production environment. A failure in a security assessment should create a failure in the pipeline to prevent poor security quality images from being uploaded to the image repository.

Kubernetes's image authentication plug-in is in the process of being completed (expected in Kubernetes 1.4), which will allow unauthenticated image packaging to be blocked.

Restrict direct access to Kubernetes nodes.

You should restrict SSH access to kubernetes nodes to reduce the risk of host resources being accessed without authentication. Accordingly, you should ask the user to use the kubectl exex command to access, which will provide direct access to the container environment without involving access to the host.

You can use Kubernetes's authorized plugin to further control users' access to resources. It allows fine-grained access control rules to be defined for specific namespaces, containers, and operations.

Create administrative boundaries between resources

Limiting the scope of user permissions can reduce the impact of misoperation or malicious operation. Kubernetes's command space allows you to divide created resources into logical naming groups. Resources created within one namespace can be separated from other naming spaces. By default, each resource created by the user in the Kubernetes cluster is under the default namespace. You can create additional namespaces and hang resources and users under that space. You can create policies through kubernetes's authorization plug-in (Authorization plugins) to isolate different users' access to resources in the space.

For example, the following policy allows "alice" to read pods under the namespace "fronto".

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "fronto", "resource": "pods", "readonly": true}} define resource quota

Running a container with unrestricted resources puts your system at risk of DoS or "noisy neighbor (noisy neighbor)". To prevent or minimize these risks, you should define resource quotas. By default, all resources created in the kubernetes cluster do not limit CPU and memory. You can create resource quota policies and associate them under namespaces to limit pod's CPU and memory consumption.

The following is an example of a resource quota definition under a namespace, which limits the number of pod to 4, the total CPU usage to 1 to 2, and the total memory to 1 to 2 gigabytes in this command space.

Compute-resources.yaml:

ApiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: pods: "4" requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi

The method of associating resource quotas to namespaces is as follows:

Kubectl create-f. / compute-resources.yaml-- namespace=myspace to achieve network segmentation

Different applications run in the same kubernetes cluster, so they will face the risk that an application that lacks resistance will attack its neighbor application. Network segmentation is important to ensure that containers can only communicate with those containers they are allowed to access.

One of the challenges in kubernetes deployment is to create network segmentation between pod, services, and containers. It is a challenge because of the "dynamic" nature of container network identification (IPs) and the fact that containers can communicate between the same node and different nodes.

Users of Google's cloud platform benefit from the platform's automatic firewall rules, which can prevent cross-cluster communication. Using a network firewall or SDN scheme, we can deploy a similar implementation locally. Kubernetes's network SIG is doing related work in this field, which can significantly improve the communication strategy between pod and pod. A new network policy API should meet the needs of users by creating firewall rules between pod to restrict network access between containers.

The following is an example of a network policy that controls the network of "backend" pod and only allows network access of "frontend" pod.

POST / apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys {"kind": "NetworkPolicy", "metadata": {"name": "pol1"}, "spec": {"allowIncoming": {"from": [{"pods": {"segment": "frontend"}], "toPorts": [{"port": 80, "protocol": "TCP"}]} "podSelector": {"segment": "backend"} use security context for pod and containers

When designing containers and pod, make sure that your pod, container and volumes are configured with a secure context. A security context is an attribute defined in the deployment yaml. It controls the security parameters that will be assigned to the pod/ container / volume. Some important parameters are as follows:

SecurityContext Setting Description SecurityContext- > runAsNonRoot Indicates that containers should run as non-root user SecurityContext- > Capabilities Controls the Linux capabilities assigned to the container. SecurityContext- > readOnlyRootFilesystem Controls whether a container will be able to write into the root filesystem. PodSecurityContext- > runAsNonRoot Prevents running a container with 'root' user as part of the pod

The following is an example of a pod definition with a security context parameter:

ApiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: # specification of the pod's containers #... SecurityContext: readOnlyRootFilesystem: true runAsNonRoot: true

When you want to run the container with elevated privileges (--privileged), you should consider using "DenyEscalatingExec" access control. This control denies exec and attach commands to pod, and those pod are running with elevated privileges, allowing host access. These pod include those that run with privileges, have access to the host IPC namespace, and have access to the host PID namespace.

Keep a log everywhere.

Kubernetes provides cluster-based logging that allows recording container activity to a central log repository. When a cluster is created, the standard output and standard error output of each container can be obtained through a Fluentd agent running on each node, which is input to the Google Stackdriver log system or Elasticsearch and viewed through Kibana.

At this point, I believe you have a deeper understanding of "what are the recommendations for deploying a secure kubernetes application?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.