inside my container: \u2013 my code \u2013 my libraries \u2013 my package manager \u2013 my app \u2013 my data<\/li>\n<\/ul>\n <\/p>\n
<\/p>\n
<\/p>\n
Locking Down and Patching Containers<\/p>\n
<\/p>\n
A regular system often contains software components that aren\u2019t required by its applications. In contrast, a proper Docker container includes only those dependencies that the application requires, as explicitly prescribed in in the corresponding Dockerfile. This decreases the vulnerability surface of the application\u2019s environment and makes it easier to lock it down. The smaller footprint also decreases the number of components that need to be patched with security updates.<\/p>\n
<\/p>\n
When patching is needed, the workflow is different from a typical vulnerability management approach:<\/p>\n
<\/p>\n
Traditionally, security patches are installed on the system independently of the application, in the hopes that the update doesn\u2019t break the app.<\/p>\n
Containers integrate the app with dependencies more tightly and allow for the container\u2019s image to be patched as part of the application deployment process.<\/p>\n
Rebuilding the container\u2019s image (e.g., \u201cdocker build\u201d) allows the application\u2019s dependencies to be automatically updated.<\/p>\n
The container ecosystem changes the work that ops might traditionally perform, but that isn\u2019t necessarily a bad thing.<\/p>\n
<\/p>\n
Running a vulnerability scanner when distributing patches the traditional way doesn\u2019t quite work in this ecosystem. What a container-friendly approach should entail is still unclear. However, it promises the advantage of requiring fewer updates, bringing dev and ops closer together and defining a clear set of software components that need to be patched or otherwise locked down.<\/p>\n
Security Benefits and Weaknesses of Containers<\/p>\n
<\/p>\n
Application containers offer operational benefits that will continue to drive the development and adoption of the platform. While the use of such technologies introduces risks, it can also provide security benefits:<\/p>\n
<\/p>\n
Containers make it easier to segregate applications that would traditionally run directly on the same host. For instance, an application running in one container only has access to the ports and files explicitly exposed by other container.<\/p>\n
Containers encourage treating application environments as transient, rather static systems that exist for years and accumulate risk-inducing artifacts.<\/p>\n
Containers make it easier to control what data and software components are installed through the use of repeatable, scripted instructions in setup files.<\/p>\n
Containers offer the potential of more frequent security patching by making it easier to update the environment as part of an application update. They also minimize the effort of validating compatibility between the app and patches.<\/p>\n
<\/p>\n
Not all is peachy in the world of application containers, of course. The security risks that come to mind when assessing how and whether to use containers include the following:<\/p>\n
<\/p>\n
The flexibility of containers makes it easy to run multiple instances of applications (container sprawl) and indirectly leads to Docker images that exist at varying security patch levels.<\/p>\n
The isolation provided by Docker is not as robust as the segregation established by hypervisors for virtual machines.<\/p>\n
The use and management of application containers is not well-understood by the broader ops, infosec, dev and auditors community yet.<\/p>\n","protected":false},"excerpt":{"rendered":"
Docker is an open platform for Sys Admins and developers to build, ship and run distributed applications. Applications are easy and quickly assembled from reusable and portable components, eliminating the silo-ed approach between development, QA, and production environments.<\/p>\n
Individual components can be microservices coordinated by a program that contains the business process logic (an evolution […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,73],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/5502"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5502"}],"version-history":[{"count":2,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/5502\/revisions"}],"predecessor-version":[{"id":5507,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/5502\/revisions\/5507"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5502"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5502"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"docker](\"http:\/\/rmohan.com\/wp-content\/uploads\/2015\/12\/docker-001.jpg\")
<\/a><\/p>\n