Container Security and DevSecOps: some old rules that are no longer applicable-Alibaba Cloud Developer Community

This article is about container Security and DevSecOps: some old rules that are no longer applicable [Editor's words] how to ensure the security of the container environment and fundamentally prevent unauthorized changes? The author believes that it is a good way to advance the time of the security control process. [Shenzhen station | 3-day brain-burning Kubernetes training camp] the training content includes: Kubernetes overview, architecture, logs and monitoring, deployment, autonomous driving, service discovery, network solutions and other core mechanism analysis, advanced section-Kubernetes scheduling working principle, resource management and source code analysis, etc. A common problem with container environments is how to ensure that only authorized images can run as containers? Various products and development teams have spent a lot of time on this issue, and want to apply the set of software and configuration standards to container management. In a traditional IT environment, two processes can be parallel: one is software development (dev.), and the other is infrastructure operation (ops.) in the software runtime environment. Mature Security control measures have been taken for these two processes. The above two processes are carried out independently. Only when the newly developed software is installed on the infrastructure can the two processes intersect. Most importantly, if there is a problem with the infrastructure configuration, it will basically be properly handled in the security control and operation process, and rarely affect software development. To ensure code security, the first step is not to simply transition it to a container application. The subsequent control steps need to be adjusted according to the containerized environment.

Containers: new rules, new security processes

the container embeds all operating system components, required components, and related settings into the image. Once the image is built and transmitted (ship), no changes should be made. Containers in the running state cannot be configured, repaired, or replaced. The only way to modify the internal environment of an image is to create a new image. That is to say, the only place where the infrastructure security method can be applied is when the image is created. Because once the image is deployed, there is no room for change.

Attention should be paid to security issues.

The security control embedded in the infrastructure has largely, or fundamentally changed the creation process. This method completely shifts the current security control process. You do not need to perform iterative evaluation, repair, and configuration adjustment until the development and integration processes are completed. Security control needs to be performed at the first time, that is, after the image is created, prior to further CI/CD (continuous integration and continuous delivery) processes. This is the real meaning of the sentence "move safety control to the front. In this process, all the elements of the infrastructure security policy need to be implemented, which is very important. In addition, there are some policies for container images: Ideally, these policies correspond to those applied in the current physical, virtual, or cloud hosts. For example, the vulnerability list that images cannot accept is basically the same as the vulnerability list that evaluates server compliance.

It's time to update security control

security organizations have been focusing on unauthorized changes for a long time. Redirect servers, manage privileged identities, manage logs, change windows, and analyze root causes to detect and prevent unauthorized changes to software components and their configurations. The internal and external continuous vulnerability assessment of the host is to measure the inevitable changes in the IT infrastructure in a timely manner. The implementation of the containerized environment seems unrealistic. It requires both dynamics and consistency. With containers, the host is no longer required because the host has no valid load or configuration meaning (except container engines). At the same time, it is no longer necessary to make changes to the running containers, because these changes will be overwritten when the container is orchestrated or recreated. In short, there is no need to make changes in the traditional sense in the future. Where changes are required, you only need to rebuild a new image to replace, add, or repair the containers that you want to modify to make them meet your expectations. If security control is introduced into this process and can operate effectively, what was previously thought impossible will be realized: More security applications have been fundamentally created, faster and more efficient than before.

Original link: Container Security and DevSecOps: The Old Rules No Longer Apply (translation: Ma Yuanzheng)

the original text was published: 2017-04-24

author: ma Yuanzheng

this article is from Dockerone.io, a partner of Yunqi community. For more information, see Dockerone.io.

Original title: container Security and DevSecOps: some old rules that are no longer applicable

Selected, One-Stop Store for Enterprise Applications
Support various scenarios to meet companies' needs at different stages of development

Start Building Today with a Free Trial to 50+ Products

Learn and experience the power of Alibaba Cloud.

Sign Up Now