Resource Quotas and Network Segmentation in Kubernetes

An option of running resource-unbound containers puts your system in risk of DoS or “noisy neighbor” scenarios. To prevent and minimize those risks you should define resource quotas. By default, all resources in Kubernetes cluster are created with unbounded CPU and memory requests/limits. You can create resource quota policies, attached to Kubernetes namespace, in order to limit the CPU and memory a pod is allowed to consume. The following is an example for namespace resource quota definition that will limit number of pods in the namespace to 4, limiting their CPU requests between 1 and 2 and memory requests between 1GB to 2GB. 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 ``` Assign a resource quota to namespace: ``` kubectl create -f ./compute-resources.yaml --namespace=myspace ``` **Implement Network Segmentation** Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. One of the challenges in Kubernetes deployments is creating network segmentation between pods, services and containers. This is a challenge due to the “dynamic” nature of container network identities (IPs), along with the fact that containers can communicate both inside the same node or between nodes. Users of Google Cloud Platform can benefit from automatic firewall rules, preventing cross-cluster communication. A similar implementation can be deployed on-premises using network firewalls or SDN solutions. There is work being done in this area by the Kubernetes [Network SIG](https://github.com/kubernetes/community/wiki/SIG-Network), which will greatly improve the pod-to-pod communication policies. A new network policy API should address the need to create firewall rules around pods, limiting the network access that a containerized can have. The following is an example of a network policy that controls the network for “backend” pods, only allowing inbound network access from “frontend” pods: ``` 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" } } } ``` Read more about Network policies [here](https://kubernetes.io/blog/2016/04/Kubernetes-Network-Policy-APIs). **Apply Security Context to Your Pods and Containers** When designing your containers and pods, make sure that you configure the security context for your pods, containers and volumes. A security context is a property defined in the deployment yaml. It controls the security parameters that will be assigned to the pod/container/volume. Some of the important parameters are:

This section discusses resource quotas and network segmentation for Kubernetes. It explains how to define resource quotas to prevent DoS attacks and 'noisy neighbor' problems by limiting CPU and memory consumption. It then covers the importance of network segmentation to isolate applications and prevent compromised applications from attacking others. It highlights the challenges due to dynamic container network identities and mentions Google Cloud Platform's automatic firewall rules as a solution. Finally, it references the Kubernetes Network SIG's work on network policy APIs and provides an example of a network policy that controls network access between pods.