Protecting the security of
Docker and
container infrastructure requires a combination of strategies, tools, and prudent application inspections.
Gartner listed container security as one of its top ten security concerns this year. It may be time to take a closer look and find a practical solution for container security. Although the container has been available for ten years, its lightweight and reusable code, flexible functions and lower development cost have made the popularity of the container unabated. But no tools are all applicable. Let us take a closer look at the various tools needed to protect the development environment, the tools used by the container itself, and the tools for monitoring/auditing/compliance purposes.
Start with the following basic steps:
1. Familiar with the tools delivered by the cloud provider
It is to be familiar with the built-in security measures of the cloud provider.
2. Familiar with native Docker related security functions
Including the use of strategies to prevent resource abuse, setting up access control groups and ensuring that unnecessary root permissions are removed.
3. Consider GitHub open source projects
In some cases, projects such as Bench Security that check the security practices in the code, and other Linux native tools like seccomp, are good choices for saving money.
There is always a lot of software to learn and understand, but you should focus on several commonly used functions, including the identity and authentication measures for users and the final application, and the mechanisms to control these access permissions. In addition, you also need to be able to check and audit log files, and to be able to browse and filter log files to provide actionable information that is beneficial to the security situation. There is also an underlying infrastructure for protecting secrets such as API keys and SSL certificates. These secrets must be stored in encrypted form.
Is it a little dizzy? This is just the beginning. If you want to protect the containers in your company environment, you have to carefully consider the following three areas.
1. Protect the development environment
Since containers are very useful to developers, it is necessary to advance to DevSecOps, but remember to add security measures when creating containers, not after the project hastily launched many loopholes. Ensuring application security has always been practice. Before choosing the right security tool, you need to answer the following important questions:
(1) Which workflows can be automated to maintain application security?
There are tools to help achieve this, especially in terms of orchestration. However, many orchestration tools focus on container management and scaling issues, and may not consider security details. Finding the right balance between function and protection may not be so easy.
(2) How fine should the granularity of application and user access control be set?
It is necessary to understand the implementation mechanism of these controls and their limitations. For example, which code segments and containers have root/kernel access permissions, and whether such high permissions are required to complete tasks.
(3) Should I use runtime application self-protection (RASP) technology?
necessary. Just like regular RASP tools that focus on applications, some tools focus on protection of container runtime applications, either with static scanning or continuous integration with the development environment. Because the container code is constantly changing, the form of continuous integration is quite useful; and having a continuous code audit can also save a lot of time when it has to be fixed or updated. A good RASP container tool should be able to mark abnormal behaviors, mitigate potential threats, and be able to isolate specific events for further forensic analysis.
2. Protect the underlying host hosting the container
In most cases, this means running a streamlined version of LInux, leaving only the necessary services to reduce the potential interface. Some tools are designed to strengthen the host itself. Another way is to use the Docker control group mentioned above and isolate the namespace to reflect your security policy and prevent mutual infection between containers. Some stores use virtual private connections from cloud providers to achieve this isolation operation. This process involves applying access levels and other mechanisms to isolate workloads and limiting the number of containers running on each host. For this reason, some stores even run only one container on a host.
3. Protect container content security
Discussed here is the mirrored software supply chain. This is the cornerstone of container construction, so an important basic function is to be able to ensure the integrity of the image source, that is, when employees or open source projects that provide the original container image make changes to the image, you have to know exactly what has been changed thing.
Given the fact that many containers are shared on the Internet, being able to scan container images to ensure that they are not infected is a very useful feature. So, how often do you scan, and can you automate the scan? It's great to be able to obtain images from trusted sources, but everyone makes mistakes and accidental introduction of security issues is inevitable.
However, for some stores, you don't have to worry about vulnerabilities in the container. This sounds surprising, but it does make sense-except for one thing: unless you can guarantee that the container boundary is sufficiently secure, or the actual code of your application does not touch the vulnerable part of the container code. Your confidence in your own security tools may be the ultimate factor in determining vulnerability tolerance.
