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.

Static code analysis tools ensure software development security by evaluating source code, checking common errors, and standardizing coding standards.
The server assessment tool checks the versions of the operating system and other components, scans for vulnerabilities and patch levels, and standardizes configuration standards to ensure the security of infrastructure operations.

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:

create an image based on a baseline image (Template)
server software components can accept certain vulnerabilities.
The server software component is the lowest version that meets the conditions. The configuration of the image operating system meets the organization standard.
Image metadata includes required elements, user environment settings, and entry point settings.

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

Please read this disclaimer carefully before you start to use the service. By using the service, you acknowledge that you have agreed to and accepted the content of this disclaimer in full. You may choose not to use the service if you do not agree to this disclaimer. This document is automatically generated based on public content on the Internet captured by Machine Learning Platform for AI. The copyright of the information in this document, such as web pages, images, and data, belongs to their respective author and publisher. Such automatically generated content does not reflect the views or opinions of Alibaba Cloud. It is your responsibility to determine the legality, accuracy, authenticity, practicality, and completeness of the content. We recommend that you consult a professional if you have any doubt in this regard. Alibaba Cloud accepts no responsibility for any consequences on account of your use of the content without verification. If you have feedback or you find that this document uses some content in which you have rights and interests, please contact us through this link: https://www.alibabacloud.com/campaign/contact-us-feedback. We will handle the matter according to relevant regulations.

Alibaba Cloud Linux 2: Optimized Native OS for Applications - Alibaba Cloud from: Site > Product > Solutions by Use Case

Cloud-Native Applications Management Solution - Alibaba Cloud from: Site > Solution > Solutions by Use Case

Elastic Container Instance (ECI): Serverless Containers - Alibaba Cloud from: Site > Product > Container & Middleware

Alibaba Cloud
Free Trial

50+ Free Offers

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

Containers: new rules, new security processes

Attention should be paid to security issues.

It's time to update security control

Start Building Today with a Free Trial to 50+ Products