Cybersecurity on Kubernetes

1. https://www.briskinfosec.com Briskinfosec Technology and Consulting Pvt Ltd Mobile: 8608634123 https://www.briskinfosec.com https://www.facebook.com/briskinfosec https://twitter.com/briskinfosec Cybersecurity on Kubernetes

2. https://www.briskinfosec.com Cybersecurity on Kubernetes Kubernetes dominates the container orchestration market. According to various reports, 87 percent of organizations are managing a portion of their container workloads with Kubernetes and this is one of the biggest technologies being adopted. And with it, we see the dark side of such early adoption. And it is that 94 percent of the organizations that use kubernetes have experienced a serious security problem in the last 12 months in their container environment, almost 70 percent have detected incorrect configurations, 27 percent have experienced incidents of cybersecurity and 24 percent have discovered significant vulnerabilities in such container environments. In general terms, each of these cybersecurity problems corresponds to a phase of the container life cycle:  We must remediate known vulnerabilities during the build phase  Fix incorrect configurations during build / deployment phase  Respond to threats at runtime. Cybersecurity Best Practices in Kubernetes: Build Phase Protecting containers and Kubernetes begins in the build phase with protecting container images. The time we spend at this point will pay dividends later. Cybersecurity best practices that have been missed at this point will be significantly more expensive to correct in later phases. The two main things to do here are creating secure images and scanning those images for known vulnerabilities .

3. https://www.briskinfosec.com Use minimal images : Avoid using images with operating system shells or package managers, as they could contain unknown vulnerabilities. If we must include operating system packages, remove their administrator in a later step. Don't add unnecessary components : Make sure to remove debugging tools from containers in production. Common tools, like CURL , are very useful for attackers, as a good hardening let's talk, delete them. Only use up-to-date images : Make sure your images (and any third-party tools it includes) are up-to- date and use the latest versions of their components. Use an image scanner to identify vulnerabilities : The scanner should be able to identify vulnerabilities within images, even in layers, and tell us whether or not they can be patched. We must be able to search for vulnerabilities in operating system packages and libraries for all containerized applications. Here you have an interesting list of vulnerability scanners for kubernetes . Integrate and automate cybersecurity : Make image scanning and other cybersecurity checks part of your channel to automate security and generate alerts when the scanner detects high but repairable vulnerabilities Tag non-fixable vulnerabilities : Sometimes, there is no fix for a known vulnerability, or the vulnerability is not critical and therefore does not guarantee an immediate fix. In this case, whitelist them or filter the scanner output so it doesn't interrupt the development team's workflow. Deploy defense in depth : When a cybersecurity issue is discovered in a container image or a running deployment that uses that image, make sure you have policy checks and a remediation workflow to detect and update those images.

4. https://www.briskinfosec.com Cybersecurity Best Practices in Kubernetes: Deployment Phase The Kubernetes infrastructure must be configured securely before deploying workloads. From a cybersecurity perspective, we first need visibility into what you are implementing and how. We can then identify and respond to security policy gaps. At a minimum, we need to know: What is being deployed : Including information about the image being used, what components or vulnerabilities, and the pods that will be deployed. Where it will be deployed : What clusters, namespaces and nodes How it is implemented : If it runs with privileges, what other implementations it can communicate with, the security context of the pod that is applied, if applicable What it can access : Including secrets, volumes, and other infrastructure components, such as the host or the Orchestrator API. It is compatible : If you comply with our cybersecurity policies and requirements With this information, you can begin to target areas for remediation and hardening and implement the appropriate segmentation. Recommendations Use namespaces to isolate sensitive workloads : Namespaces are a key isolation boundary for Kubernetes resources. They provide a reference for network policies, access control restrictions, and other important security controls. Separating workloads into namespaces can help contain attacks and limit the impact of errors or destructive actions by authorized users. Uses network policies to control traffic Kubernetes ( input / output ) between pods and clusters In a manner default, Kubernetes allows each pod contact with others. Network segmentation policies are a

5. https://www.briskinfosec.com key security control that can prevent lateral movement through containers should an attacker break in. We covered how to configure Kubernetes network policies in two previous blog posts. Avoid over-permissioned access to secrets : As a first step, make sure your deployments collect only the secrets they actually require to avoid unnecessary exposure. Evaluate the privileges used by containers : The set of capabilities, roles and privileges granted to containers can have a great impact on cybersecurity. The goal here is to adhere to the principle of least privilege and provide the minimum privileges and capabilities that would allow the container to perform its function. The cybersecurity policies of the pods are a way to control the attributes related to it in these, including levels of privilege of the containers. These can allow an operator to specify the following:  Do not run the application processes as root.  Do not allow privilege escalation.  Use a read-only root file system.  Use default file system mount (proc)  Do not use the host network or compute space.  Remove unused and unnecessary Linux capabilities.  Use SELinux options for more detailed process controls.  Grant each application its own Kubernetes service account. Don't mount the service account credentials in a container if you don't need to access the Kubernetes API .

6. https://www.briskinfosec.com Assess image provenance, including logs : As a general rule, do not implement code from unknown sources. For Kubernetes, this means using images of known records that are only on allow lists. Extends image scanning : As an extension of image scanning, it enforces policies in the deployment phase based on the scan results. One way to enforce this would be to use the validation admission handler , a Kubernetes feature to reject deployment creation when they specify images with no scan results or critical vulnerabilities, or if images were created more than 90 days ago. Images that have not been scanned recently may contain vulnerabilities with what this entails. Use tags and annotations appropriately : For example, consider tagging or annotating deployments with the name, email alias, or Slack channel of the team responsible for an app. This will make it easier to alert the responsible team to the classification of cybersecurity issues. Enables Kubernetes role- based access control (RBAC) , this provides a method to control authorization to access a cluster's Kubernetes API server, for both users and service accounts in the cluster. The Kubernetes RBAC feature is highly configurable. Cybersecurity Best Practices in Kubernetes: Execution Phase The execution phase exposes containerized applications to a host of new cybersecurity challenges. Our goal here is to gain visibility into the runtime environment, and detect / respond to threats as they arise. Proactively protecting your containers and Kubernetes deployments in the build and deployment phases can greatly reduce the likelihood of cybersecurity incidents in the execution phase and the subsequent effort required to correct errors. First, we must monitor the container activities most relevant to cybersecurity:  Process activity

7. https://www.briskinfosec.com  Network communications between containerized services  Network communications between containerized services and external clients and servers Observing container behavior for anomalies is generally easier on containers than virtual machines due to the declarative nature of containers and Kubernetes . These attributes allow to know in a simpler way, what has been implemented and its expected activity. Recommendations Take advantage of contextual information in Kubernetes : Use build-time and deployment information in Kubernetes to evaluate observed versus expected activity at runtime to detect suspicious activity. Extends vulnerability scanning to running deployments : Monitors running deployments for Zero Day vulnerabilities, as well as scanning for vulnerabilities that exist in container images. Use Kubernetes' built-in cybersecurity controls : Set the cybersecurity context for pods to limit their capabilities. These controls can eliminate entire classes of attacks that depend on privileged access . Monitor network traffic to limit unnecessary or insecure communications : Observe network traffic and compare that traffic with that allowed according to Kubernetes policies. Observing active network traffic is a good way to understand how applications interact with each other and to identify unexpected communications. At the same time, comparing active traffic with what is allowed gives us valuable information about what is not happening but is allowed. With that information, we can further fine-tune the allowed policies to decrease the attack surface. Open source projects like https://github.com/kinvolk/inspektor-gadget can help with this, and commercial security solutions provide varying degrees of container network traffic analytics.

8. https://www.briskinfosec.com Allow List Leverage Process : The process of using whitelisting is a proven practice for identifying unexpected running processes. First, you observe the application over a period of time to identify all the processes that are running in the normal course of application behavior, then use this list as your list of allowed processes in order to compare the future behavior of the application. Compare and analyze different runtime activities in pods : Containerized applications are replicated for high availability, fault tolerance, or scale reasons. The replicas should behave almost identically, the replicas with significant deviations from the others warrant further investigation and a priori suspicion. Integrate the Kubernetes cybersecurity tool with other external systems : Email, PagerDuty, Slack, Google Cloud Security Command Center, SIEM , etc.) and take advantage of alerting the team responsible for a specific application when a potential threat is detected. Kubernetes commercial security providers must support a wide range of integrations with external tools. Use native Kubernetes controls to contain a cybersecurity breach : Automatically instruct Kubernetes to scale suspicious pods to zero or kill and then restart the infringed application instances.