| Stage | Protect |
| Maturity | Minimal |
| Content Last Reviewed | 2020-12-08 |
Thanks for visiting this category direction page on Container Host Security in GitLab. This page belongs to the Container Security group of the Protect stage and is maintained by Sam White (swhite@gitlab.com).
This direction page is a work in progress, and everyone can contribute. We welcome feedback, bug reports, feature requests, and community contributions.
/label ~"devops::protect" ~"Category:Container Host Security" ~"group::container security".
We believe everyone can contribute and so if you wish to contribute here is how to get started.
Container Host Security (CHS) refers to the ability to detect, report, and respond to attacks on containerized infrastructure and workloads. Techniques include use of one or more types of intrusion detection systems (IDS) to detect attacks. The IDS may be supplemented with custom-built monitoring capabilities and/or behavior analytics to improve the efficacy and scope of detected attacks.
An IDS is a device or software application that monitors a network or systems for malicious activity or policy violations. Malicious activity can then be reported back to an Administrator either through GitLab or through a security information and event management (SIEM) system. IDS types range in scope from single computers to large networks. The most common classifications are network intrusion detection systems (NIDS) and host-based intrusion detection systems (HIDS). Some leverage honeypots to attract and characterize malicious traffic. Some strictly leverage signature-based detection, while others use machine learning to automatically detect anomalies.
An ideal Container Host Security solution would include all types of intrusion detection systems to provide defense-in-depth and protection against a wide range of attacks. Additional analytics can be layered on top of the data collected from an IDS to help filter out false positives and to recommend new rules to reduce false negatives.
We are planning to build a Container Host Security solution that is cloud native, easy to use, and tightly integrated with the rest of GitLab. Our underlying architecture will combine several technologies to create a full-featured solution while also simplifying and unifying the management experience to look and feel like a single, easy-to-use product. We plan to be both a host-based IDS and an IPS, allowing users to choose to either log, alert, or block any activity that is detected in their containerized environments.
Some of the top detection and protection capabilities that we provide today include application allow listing and file integrity monitoring. To better manage these capabilities, we plan to provide an intuitive policy editor to simplify the administration of the tool. We also plan to surface actionable alerts and logs inside GitLab to allow for a simple triage and response workflow to detected attacks. Longer-term we plan to add additional behavior analytics on top of our host security to improve our threat detection capabilities.
Q4 FY'21 - (November 2020 - January 2021)
Q1 FY'22 - (February 2021 - April 2021)
Q2 FY'22 - (May 2021 - July 2021)
Q3 FY'22 - (August 2021 - October 2021)
Q4 FY'22 - (November 2021 - January 2022)
Future / TBD
The next step for Container Host Security is to allow these capabilities (Falco, AppArmor, and Pod Security Policies) to be installed through the Gitlab Kubernetes Agent.
We are not currently planning to do the following:
We plan to measure the success of this category based on the total number of monthly alerts generated by our Container Host Security solution across our entire customer base.
The Container Network Security provides security at the network layer. This category is critical to securing a containerized environment as it extends the security controls to protect against attacks inside the running container.
Top competitors:
Key features offered by competitors:
Gartner defines two markets that are relevant to this category:
Of these two markets, the second aligns more closely with where we are headed as we are focused on cloud and containerized workload protection rather than attempting to be a generic IDS/IPS for all types of workloads. <!–
We will need to integrate an IDS as an important first step toward our strategy.
Additional strategy items will be uncovered as we do more research in this area.
