Security is still a major problem for container and Kubernetes developers. According to the Red Hat 2022 State of Kubernetes security study, 93 percent of respondents had at least one security issue in their Kubernetes settings in the preceding year. Furthermore, 31% of respondents blamed these security events for revenue or client loss.
There are several methods available to increase security in an increasingly dangerous software development environment, including intrusion detection systems, code scanners, and others. Unfortunately, few of them are designed with the specific risks and requirements of a Kubernetes system in mind. However, there are alternatives. This post will compare eight open source security technologies developed for Kubernetes:
KubeLinter
Kube-bench
Kube-hunter
Falco
Terrascan
Checkov
Open Policy Agent (OPA)
Container Security Operator
But, before we get into the specifics of the tools, let's go through some of the underlying ideas.
Requirements for security tools
Some of the safeguards required by Kubernetes are the same as those required by any other network-connected host. You don't want to open unnecessary ports, which might occur if you execute an image that has a service, such as a database, that you don't require. Likewise, you don't want processes that accept web requests to execute as root.
However, many vulnerabilities in Kubernetes applications are exclusive to containers or Kubernetes orchestration. Allowing a container to use the same IP address as the host operating system on which the container is executing, for example, is risky. This issue may allow containers to communicate with one another, violating the fundamental tenet of containerization, which requires container isolation. If you utilise the host system's address, the majority of the tools in this article will indicate a vulnerability.
Now, there may be situations when you want a container to utilise the host's IP address. If that's the case, most of the tools in this post will allow you to deactivate individual tests like this one.
Profiling in the Controller Manager is just another example of a Kubernetes-specific vulnerability. This feature can be beneficial for troubleshooting a sluggish cluster for brief periods of time, but in general, profiling should be turned off in the Controller Manager. This issue is mentioned in several of the tools in this post.
Some vulnerabilities result from a failure to update an outdated configuration to suit Kubernetes' progress. Helm Tiller, for example, was formerly deployed on clusters but was shown to be problematic and is now deprecated. Nonetheless, many setups have not modified their ways.
Other vulnerabilities might arise as a result of inattention or ignorance. Several programmes, for example, check to see whether you have a password or other susceptible information in a ConfigMap. For such information, Kubernetes supports key-protected Secrets.
A rough classification
There are several ways to categorise the tools in this page. Some are static, looking over your manifests (configurations). Others are dynamic, running within clusters to verify their settings or outside the clusters to hunt for publicly accessible vulnerabilities.
Some of the dynamic tools are passive, which means they do tasks such as port scans to monitor the activity of the Kubernetes cluster. Others are hard at work, conducting penetration tests to assess how the cluster reacts to an attack.
The tools do not attempt to solve issues; instead, they just report them. Remediation would need an additional layer of system access. Furthermore, it is safer to just report an issue to a human administrator, who will then choose if and how to resolve it.
The first six tools in this paper work with manifestations in one of three ways. The latter two, OPA and Container Security Operator, do not inspect manifests. They provide additional security.
There are also several methods for interacting with the tools. Some just provide a command-line interface (CLI), while others provide an API for integration with automated systems.
Now we'll focus on each tool individually.
KubeLinter
KubeLinter is a vulnerability scanner that follows in the footsteps of the venerable Unix lint programme. Some of the issues discovered by KubeLinter are clear security flaws, such as putting a Secret in an environment variable or permitting dangerous privilege escalation.
However, KubeLinter, like other linters, looks for problematic activities that are most likely incorrect and may indirectly contribute to security flaws. Other tests performed by the tool may help you remove waste and increase performance or availability, such as ensuring that at least three replicas are operating and incorporating a liveness probe.
KubeLinter is a command-line tool that can be easily hooked to run automatically on each Git commit. KubeLinter, in other words, can be integrated into your automated CI/CD processes. It can run on a single file or on a whole directory. It is thus, like other linters, a static analysis tool.
According to KubeLinter's website, the tool is still in its early stages of development and presently includes 46 inspections.
kube-bench
kube-bench is a comprehensive static analysis tool based on a benchmark developed by the Center for Internet Security (CIS). CIS is a non-profit membership organisation that provides its benchmarks for free download and implementation; however, the benchmarks are not open source.
It's worth mentioning that the Kubernetes benchmark is only one of CIS's many hundreds that give secure practises for mobile devices, operating systems (including Red Hat Enterprise Linux and CentOS), cloud suppliers, and other technologies.
The majority of the benchmarks involve the execution of a basic command to check for a running process, file permissions, and so on. However, some CIS tasks cannot be completely automated.
The link between kube-bench and the CIS Kubernetes Benchmarks is in change since each version of Kubernetes requires somewhat different benchmarks. kube-bench attempts to establish your Kubernetes version before running tests written as YAML commands. If you pass the tests, you can be reasonably certain that your system meets the benchmarks (although the CIS terms of service prohibit you from saying so).
kube-bench, like KubeLinter, can run statically but can also scan a running cluster. Aqua created and distributed kube-bench as free source. The utility is made up of YAML and Go language files.
kube-hunter
Aqua's kube-hunter is another open source Kubernetes security tool implemented in Python. It runs dynamically and includes 23 passive and 13 active tests. You may select which tests to perform and on which IP addresses, domain names, or networks.
KubeLinter and kube-bench are fairly esoteric, displaying what are considered undesirable practises. kube-hunter is more practical, operating alongside your Kubernetes cluster and hitting it with standard intrusion detection tools like port scanners and penetration tests.
Falco
The programme is described as a "Kubernetes threat detection engine" on the Falco website. Falco began as a static checker for the Linux kernel, checking for basic system-level errors such as the construction of a symbolic link, a change in file ownership, and so on.
Falco now provides a sophisticated analysis tool for Kubernetes, which is integrated with the Kubernetes audit logging capability. Many Falco tests are for pods with improper permissions.
Sysdig established the Falco project, which is currently an incubation project at the Cloud Native Computing Foundation (CNCF), the most prominent open source organisation in cloud computing.
Terrascan
Terrascan is a dynamic analysis tool that operates independently and interacts with its target. Terrascan can integrate with a variety of settings, including Kubernetes and CI/CD pipelines on GitHub and GitLab.
Terrascan interfaces with Kubernetes using admission webhooks, which let an administrator to run an external script or tool when Kubernetes gets specific sorts of requests.
Terrascan provides a CLI as well as an API and enables for extensive customization. Terrascan, for example, assigns severities (low, medium, or severe) to its Kubernetes rules, allowing you to instruct it to disregard low-risk behaviours.
Checkov
Checkov is capable of doing hundreds of scans against a Kubernetes cluster. Many of its checks, as one might assume, are comparable to those in kube-bench and other tools discussed in this article.
Although Checkov was designed to be static, it may now now function against a running cluster. Python is used to write it.
Open Policy Agent
The Open Policy Agent (OPA) is not a vulnerability scanner like the other technologies discussed in this article. Instead, it is a collection of regulations that are implemented by a runtime daemon. If you spent a long time learning how to setup iptables, prepare to repeat the process. Open Policy Agent functions similarly to a firewall, enforcing various restrictions on Kubernetes activity.
OPA is a highly active monster, always assessing resources for compliance. The documentation provides an example of someone attempting to create a host with a name that is already in use by another operating host. If you want it to, OPA can detect the error and prevent the duplicate name from being formed.
OPA also has a lot of features. You may use an API or a command line interface to add policies and control OPA. OPA even provides unit testing, in which you make a request to a policy and evaluate whether the output matches what you intended.
OPA may respond to dynamic demands from third parties. For example, you may grant a user permission to conduct an action, such as deleting a file.
Rego, the vocabulary used by OPA to define policy requires some explanation. Declarative policies are used: One statement may check to see whether a host exists, while another may check to see if it is using the insecure HTTP protocol. The daemon moves on to the next statement as long as each statement returns true results. Administrators typically begin with a list of requirements and then act at the end.
Rego is complicated, but it enables for easy layering of rules, which eliminates the need to repeat oneself. For example, if one group of hosts is restricted to port 80 and another to port 5432, you may call the first limitation web and the second postgresql. Then, in the definition of each host, you may mention the relevant rule. If you want to change the web port to 8080, you may do it in the rule rather than having to modify the specification for each host.
While you're dealing with Rego, think of your job as a cameo in a historical re-enactment. Rego's ideas and syntax may be traced back to the early 1960s Prolog language, which is widely regarded as the first declarative language. Take joy in returning to the foundations of a proud history because both Kubernetes manifests and current configuration tools (Ansible, Puppet, Chef, and so on) are declarative.
Clair and the Container Security Operator
Clair belongs to the static analysis tools category. It builds an inventory of all dependencies utilised by a container image, scanning the image to inventory all installed apps, operating system components, and libraries. Clair, like several of the other tools mentioned in this post, compares each dependency to public databases that report software vulnerabilities. It also refreshes the inventory anytime a new vulnerability is disclosed, so you are aware of new vulnerabilities not just when you develop your image, but also whenever a vulnerability that potentially affect your image is reported.
In summary, when you run your container image via Clair, it maintains track of changes to your code as well as the vulnerability listings that have been updated to all of your dependencies.
Clair was intended to operate with container registries by the same team that produced Quay.io. Many organisations have embraced it and use it to test their own apps and libraries, maintaining their inventories on their own systems.
Container Security Operator may be used to scan for Kubernetes vulnerabilities. Red Hat initiated both Clair and the Container Security Operator as open source projects.
Conclusion
Kubernetes is a complicated environment with several attack vectors. The tools in this post assist you in securing your apps and containers in many ways, reducing your attack surface and overall risk.
Comments