DOCSLIB.ORG

Understanding and Hardening Linux Containers June 29, 2016 – Version 1.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Understanding and Hardening Linux Containers June 29, 2016 – Version 1.1 NCC Group Whitepaper Understanding and Hardening Linux Containers June 29, 2016 – Version 1.1 Prepared by Aaron Grattafiori – Technical Director Abstract Operating System virtualization is an attractive feature for efficiency, speed and mod- ern application deployment, amid questionable security. Recent advancements of the Linux kernel have coalesced for simple yet powerful OS virtualization via Linux Containers, as implemented by LXC, Docker, and CoreOS Rkt among others. Recent container focused start-ups such as Docker have helped push containers into the limelight. Linux containers offer native OS virtualization, segmented by kernel names- paces, limited through process cgroups and restricted through reduced root capa- bilities, Mandatory Access Control and user namespaces. This paper discusses these container features, as well as exploring various security mechanisms. Also included is an examination of attack surfaces, threats, and related hardening features in order to properly evaluate container security. Finally, this paper contrasts different container defaults and enumerates strong security recommendations to counter deployment weaknesses– helping support and explain methods for building high-security Linux containers. Are Linux containers the future or merely a fad or fantasy? This paper attempts to answer that question. Table of Contents 1 Introduction ................................................................................ 5 1.1 Motivation ........................................................................... 6 1.2 Virtualization Background ............................................................. 7 1.3 Benefits of An OS-Virtualization System ................................................. 10 1.4 Drawbacks of an OS-Virtualization system ............................................... 11 2 Linux Containers Overview .................................................................. 13 2.1 A Brief History of OS Containers ....................................................... 13 2.2 Linux Containers: where are they now? ................................................. 13 2.3 Prior Art: Linux Container Security, Auditing and Presentations ............................ 15 2.4 TL;DR Linux Containers ............................................................... 18 3 Namespaces ................................................................................ 20 3.1 Namespaces Background ............................................................. 20 3.2 Namespaces Implementation .......................................................... 20 3.3 Mount Namespace ................................................................... 21 3.4 IPC Namespace ...................................................................... 21 3.5 UTS Namespace ..................................................................... 22 3.6 PID Namespace ...................................................................... 22 3.7 Network Namespace ................................................................. 23 3.8 User Namespace ..................................................................... 26 4 Control Groups ............................................................................. 27 4.1 Cgroups Background ................................................................. 27 4.2 Working with Vanilla cgroups .......................................................... 28 4.3 Containers and cgroups .............................................................. 29 4.4 Future of cgroups .................................................................... 29 5 Capabilities ................................................................................ 30 5.1 Capabilities Background .............................................................. 30 5.2 Additional Introductory Resources ..................................................... 31 2 | Understanding and Hardening Linux Containers NCC Group 5.3 Understanding Capabilities ........................................................... 31 5.4 Exploring Capabilities ................................................................ 37 5.5 Capabilities and User Namespaces ..................................................... 39 5.6 Capability Defaults In Modern Containers ............................................... 40 5.7 A World Without Root ................................................................ 42 6 Configuration and Basic Use ................................................................ 43 6.1 LXC ................................................................................. 43 6.2 Docker .............................................................................. 45 6.3 CoreOS Rocket ...................................................................... 46 7 Understanding Container Threats ............................................................ 49 7.1 The Linux Kernel Itself ................................................................ 49 7.2 Exploring Container Threats ........................................................... 51 7.3 LXC Specific Threats .................................................................. 61 7.4 Docker Specific Threats ............................................................... 62 7.5 CoreOS Rkt Specific Threats ........................................................... 63 7.6 Indirect or Unexpected Threats ........................................................ 64 8 Recent Security Advancements .............................................................. 66 8.1 The User Namespace ................................................................. 66 8.2 Mandatory Access Control ............................................................ 69 8.3 Syscall Filtering with Seccomp ......................................................... 74 9 LXC, Docker and CoreOS Rocket ............................................................ 82 9.1 LXC ................................................................................. 82 9.2 LXC Background ..................................................................... 82 9.3 LXC Components .................................................................... 83 9.4 Brief LXC Security Analysis ............................................................ 83 9.5 Docker .............................................................................. 85 9.6 Docker Background .................................................................. 85 9.7 Docker Components ................................................................. 86 3 | Understanding and Hardening Linux Containers NCC Group 9.8 Brief Docker Security Analysis ......................................................... 87 9.9 CoreOS Rocket ...................................................................... 92 9.10 CoreOS and Rkt Background .......................................................... 92 9.11 Rkt Components ..................................................................... 93 9.12 Rkt Security Analysis .................................................................. 94 9.13 Container Defaults ................................................................... 97 10 Security Recommendations ................................................................. 98 10.1 Generation Container Recommendations ............................................... 98 10.2 LXC Specific Recommendations .......................................................105 10.3 Docker Specific Recommendations .....................................................106 10.4 CoreOS Rkt Specific Recommendations ................................................109 10.5 Relevant Kernel Hardening ............................................................110 11 The Future .................................................................................. 113 11.1 Containers on the Desktop ............................................................113 11.2 New Potential Namespaces ............................................................114 11.3 Additional Lightweight Isolation and Sandbox Platforms ..................................114 11.4 The Open Container Initiative..........................................................116 11.5 Containers In Other Platforms .........................................................117 11.6 Container Specific Operating Systems ..................................................117 11.7 Unikernels and Microhypervisors and Hybrid Models .....................................118 11.8 The Big Idea Of Microservices .........................................................120 12 The End .................................................................................... 122 12.1 Conclusion ..........................................................................122 12.2 Acknowledgements ..................................................................122 12.3 About The Author ....................................................................123 4 | Understanding and Hardening Linux Containers NCC Group 1 Introduction ``I am large, I contain multitudes'' – Walt Whitman Linux containers have recently developed into a production-ready technology for OS level virtualization,1 yet very little security research or best practices have been made public, and concerns for deployment2 and security3, 4 abound. This whitepaper seeks to expand on what little security information exists on what con- tainer technologies are capable of and can ultimately provide. This paper starts by examining how
Load more

Recommended publications
  • Administration and Reference Guide
    Oracle® Database Appliance Administration and Reference Guide Release 12.2.1.4.0 for Linux x86-64 E97563-01 June 2018 Oracle Database Appliance Administration and Reference Guide, Release 12.2.1.4.0 for Linux x86-64 E97563-01 Copyright © 2014, 2018, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency- specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
    [Show full text]
  • RACF Tips Volume 3, Issue 1, January 2009
    Volume 3 Issue 1 IPS RSH RACF T January For Administrators, Auditors, and Analysts 2009 Specifying a Replacement ID used to change a file's attributes for Program Control, APF Authorized, and Shared Library. with IRRRID00 . To generate commands to delete an ID and all references to it, use RACF's IRRRID00 utility. You simply enter the ID in the SYSIN DD Temporary Access with statement of the IRRRID00 job like so: CONNECT REVOKE(date) //SYSIN DD * USERX You may occasionally need to permit a user temporary access to a resource. One way to do If USERX is the owner of a profile or connect, so is to grant a group access to the resource IRRRID00 generates commands like: and connect the user to that group with a revoke date. The command to set the connect revoke CONNECT RDSADM GROUP(RACFSTC) OWNER(?USERX) date would look something like this: In these cases, you need to change ?USERX to CONNECT USERA GROUP(TEMPACC) REVOKE(1/20/09) a valid replacement ID. This can be done manually or with ISPF EDIT CHANGE. On the date specified with the revoke, RACF will no longer allow the user to have the access Alternatively, you can tell IRRRID00 which permitted to the group. If you want to remove the replacement ID to use when it builds the revoke date but leave the connect intact, enter: commands. If, for instance, you want to replace every occurrence of USERX with USERJ, enter CONNECT USERA GROUP(TEMPACC) NOREVOKE the following in the SYSIN DD: A banking client of ours used this capability to //SYSIN DD * govern access to APF-authorized libraries.
    [Show full text]
  • Google Android
    Google Android 2008/3/10 NemusTech, Inc. Lee Seung Min 네무스텍㈜ Agenda Introduction Mobile Platform Overview Background : Current Linux Mobile Platform What is Android? Features Architecture Technical Detail Android SDK Porting Android to Real Target Future of Android A conceptual model for mobile software Software Stack Kernel the core of the SW (HW drivers, memory, filesystem, and process management) Middleware The set of peripheral software libraries (messaging and communication engines, WAP renders, codecs, etc) Application Execution Environment An application manager and set APIs UI framework A set of graphic components and an interaction framework Application Suite The set of core handset application ( IDLE screen, dialer, menu screen, contacts, calendar, etc) Mobile Platforms Feature Phone Vendor Platform : Mocha, PDK, WAVE, WISE, KX, etc...... Carrier Platform : SKTelecom TPAK, NTT i-Mode (WAP), Java, WIPI, BREW, etc…… 3rd Party Solution : TAT Cascade, Qualcomm uiOne Smart Phone MicroSoft Windows Mobile Nokia : Symbian, Series 60 Apple, iPhone – OSX 10.5 Leopard Linux Customers & Licensees Not all customers or licensees are shown Source:vendor data Smartphone OS Market Share by Region Smartphone OS market share by region, 2006 Source : Canalys Current Linux Mobile Platforms LiMo Foundation https://www.limofoundation.org/sf/sfmain/do/home TrollTech Qtopia GreenPhone Acquired by Nokia OpenMoko : GNU/Linux based software development platform http://www.openmoko.org , http://www.openmoko.com Linux
    [Show full text]
  • LS-09EN. OS Permissions. SUID/SGID/Sticky. Extended Attributes
    Operating Systems LS-09. OS Permissions. SUID/SGID/Sticky. Extended Attributes. Operating System Concepts 1.1 ys©2019 Linux/UNIX Security Basics Agenda ! UID ! GID ! Superuser ! File Permissions ! Umask ! RUID/EUID, RGID/EGID ! SUID, SGID, Sticky bits ! File Extended Attributes ! Mount/umount ! Windows Permissions ! File Systems Restriction Operating System Concepts 1.2 ys©2019 Domain Implementation in Linux/UNIX ! Two types domain (subjects) groups ! User Domains = User ID (UID>0) or User Group ID (GID>0) ! Superuser Domains = Root ID (UID=0) or Root Group ID (root can do everything, GID=0) ! Domain switch accomplished via file system. ! Each file has associated with it a domain bit (SetUID bit = SUID bit). ! When file is executed and SUID=on, then Effective UID is set to Owner of the file being executed. When execution completes Efective UID is reset to Real UID. ! Each subject (process) and object (file, socket,etc) has a 16-bit UID. ! Each object also has a 16-bit GID and each subject has one or more GIDs. ! Objects have access control lists that specify read, write, and execute permissions for user, group, and world. Operating System Concepts 1.3 ys©2019 Subjects and Objects Subjects = processes Objects = files (regular, directory, (Effective UID, EGID) devices /dev, ram /proc) RUID (EUID) Owner permissions (UID) RGID-main (EGID) Group Owner permissions (GID) +RGID-list Others RUID, RGID Others ID permissions Operating System Concepts 1.4 ys©2019 The Superuser (root) • Almost every Unix system comes with a special user in the /etc/passwd file with a UID=0. This user is known as the superuser and is normally given the username root.
    [Show full text]
  • MLNX OFED Documentation Rev 5.0-2.1.8.0
    MLNX_OFED Documentation Rev 5.0-2.1.8.0 Exported on May/21/2020 06:13 AM https://docs.mellanox.com/x/JLV-AQ Notice This document is provided for information purposes only and shall not be regarded as a warranty of a certain functionality, condition, or quality of a product. NVIDIA Corporation (“NVIDIA”) makes no representations or warranties, expressed or implied, as to the accuracy or completeness of the information contained in this document and assumes no responsibility for any errors contained herein. NVIDIA shall have no liability for the consequences or use of such information or for any infringement of patents or other rights of third parties that may result from its use. This document is not a commitment to develop, release, or deliver any Material (defined below), code, or functionality. NVIDIA reserves the right to make corrections, modifications, enhancements, improvements, and any other changes to this document, at any time without notice. Customer should obtain the latest relevant information before placing orders and should verify that such information is current and complete. NVIDIA products are sold subject to the NVIDIA standard terms and conditions of sale supplied at the time of order acknowledgement, unless otherwise agreed in an individual sales agreement signed by authorized representatives of NVIDIA and customer (“Terms of Sale”). NVIDIA hereby expressly objects to applying any customer general terms and conditions with regards to the purchase of the NVIDIA product referenced in this document. No contractual obligations are formed either directly or indirectly by this document. NVIDIA products are not designed, authorized, or warranted to be suitable for use in medical, military, aircraft, space, or life support equipment, nor in applications where failure or malfunction of the NVIDIA product can reasonably be expected to result in personal injury, death, or property or environmental damage.
    [Show full text]
  • Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4
    SUSE Linux Enterprise Server 12 SP4 Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4 Provides information about how to manage storage devices on a SUSE Linux Enterprise Server. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xii 2 Giving Feedback xiv 3 Documentation Conventions xiv 4 Product Life Cycle and Support xvi Support Statement for SUSE Linux Enterprise Server xvii • Technology Previews xviii I FILE SYSTEMS AND MOUNTING 1 1 Overview
    [Show full text]
  • Security Assurance Requirements for Linux Application Container Deployments
    NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 October 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology NISTIR 8176 SECURITY ASSURANCE FOR LINUX CONTAINERS National Institute of Standards and Technology Internal Report 8176 37 pages (October 2017) This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. This p There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each ublication is available free of charge from: http publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.
    [Show full text]
  • Xen Enterprise
    Xen: the Past, Present and Exciting Future Ian Pratt Chairman of Xen.org, SVP and Founder of Bromium Sponsored by: & 1 Outline • Community Update • Xen 4 Review • Xen and the next wave of virtualization 2 COMMUNITY UPDATE 3 2011 Highlights • Inclusion of Xen into Linux 3 (and distros) • New Initiatives: – Project Kronos – Xen.org Governance – Renewed focus on Xen for ARM • Successful Community Initiatives – Documentation Day – Google Summer of Code – Hackathons: Cambridge (Citrix) and Munich (Fujitsu) • Lars Kurth: (not so) new Community Manager 4 Contribution Statistics By Change Sets Contributors to Xen.org 5000.0 200 4500.0 180 4000.0 160 3500.0 140 3000.0 120 XenARM** 2500.0 100 PVOPS Individuals 2000.0 XCP 80 Orgs 1500.0 Xen HV 60 1000.0 40 500.0 20 0.0 0 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011* *) End of Sept 2011 **) Activity on Development branch (not yet in xen-unstable) 5 2010 & 2011 Contributors (by KLOC) 2010** 2011** *** 1% 2% 3% 4% 5% 4% 6% 5% Citrix HV 28% Citrix XCP Citrix XCP 5% Citrix HV Oracle Samsung* 39% 11% Intel Novell 6% Novell Oracle Fujitsu AMD 7% AMD Individual Individual 13% Intel Misc 18% Misc 8% University 20% 15% *) Activity on Development branch (not yet in xen-unstable) **) Includes PVOPS ***) Until Sept 2011 6 Developer mailing list traffic Conversations, excluding patches excluding Conversations, 1000 1500 2000 2500 500 0 Oct-03 Dec-03 Feb-04 Apr-04 Jun-04 Aug-04 Oct-04 Dec-04 Feb-05 Apr-05 Jun-05 Aug-05 Oct-05 Dec-05 Feb-06 Apr-06 Jun-06 Aug-06 Oct-06 Dec-06 xen-devel Feb-07 Apr-07 Jun-07 Aug-07
    [Show full text]
  • ECE 598 – Advanced Operating Systems Lecture 19
    ECE 598 { Advanced Operating Systems Lecture 19 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 7 April 2016 Announcements • Homework #7 was due • Homework #8 will be posted 1 Why use FAT over ext2? • FAT simpler, easy to code • FAT supported on all major OSes • ext2 faster, more robust filename and permissions 2 btrfs • B-tree fs (similar to a binary tree, but with pages full of leaves) • overwrite filesystem (overwite on modify) vs CoW • Copy on write. When write to a file, old data not overwritten. Since old data not over-written, crash recovery better Eventually old data garbage collected • Data in extents 3 • Copy-on-write • Forest of trees: { sub-volumes { extent-allocation { checksum tree { chunk device { reloc • On-line defragmentation • On-line volume growth 4 • Built-in RAID • Transparent compression • Snapshots • Checksums on data and meta-data • De-duplication • Cloning { can make an exact snapshot of file, copy-on- write different than link, different inodles but same blocks 5 Embedded • Designed to be small, simple, read-only? • romfs { 32 byte header (magic, size, checksum,name) { Repeating files (pointer to next [0 if none]), info, size, checksum, file name, file data • cramfs 6 ZFS Advanced OS from Sun/Oracle. Similar in idea to btrfs indirect still, not extent based? 7 ReFS Resilient FS, Microsoft's answer to brtfs and zfs 8 Networked File Systems • Allow a centralized file server to export a filesystem to multiple clients. • Provide file level access, not just raw blocks (NBD) • Clustered filesystems also exist, where multiple servers work in conjunction.
    [Show full text]
  • How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise
    How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise Abstract This paper will document a process to create a custom Live CD for secure remote incident handling on Windows and Linux systems. The process will include how to configure SSH for remote access to the Live CD even when running behind a NAT device. The combination of customization and secure remote access will make this process valuable to incident handlers working in enterprise environments with limited remote IT support. Bert Hayes, [email protected] How to Create a Custom Live CD for Remote Incident Handling 2 Table of Contents Abstract ...........................................................................................................................................1 1. Introduction ............................................................................................................................5 2. Making Your Own Customized Debian GNU/Linux Based System........................................7 2.1. The Development Environment ......................................................................................7 2.2. Making Your Dream Incident Handling System...............................................................9 2.3. Hardening the Base Install.............................................................................................11 2.3.1. Managing Root Access with Sudo..........................................................................11 2.4. Randomizing the Handler Password at Boot Time ........................................................12
    [Show full text]
  • In Search of the Ideal Storage Configuration for Docker Containers
    In Search of the Ideal Storage Configuration for Docker Containers Vasily Tarasov1, Lukas Rupprecht1, Dimitris Skourtis1, Amit Warke1, Dean Hildebrand1 Mohamed Mohamed1, Nagapramod Mandagere1, Wenji Li2, Raju Rangaswami3, Ming Zhao2 1IBM Research—Almaden 2Arizona State University 3Florida International University Abstract—Containers are a widely successful technology today every running container. This would cause a great burden on popularized by Docker. Containers improve system utilization by the I/O subsystem and make container start time unacceptably increasing workload density. Docker containers enable seamless high for many workloads. As a result, copy-on-write (CoW) deployment of workloads across development, test, and produc- tion environments. Docker’s unique approach to data manage- storage and storage snapshots are popularly used and images ment, which involves frequent snapshot creation and removal, are structured in layers. A layer consists of a set of files and presents a new set of exciting challenges for storage systems. At layers with the same content can be shared across images, the same time, storage management for Docker containers has reducing the amount of storage required to run containers. remained largely unexplored with a dizzying array of solution With Docker, one can choose Aufs [6], Overlay2 [7], choices and configuration options. In this paper we unravel the multi-faceted nature of Docker storage and demonstrate its Btrfs [8], or device-mapper (dm) [9] as storage drivers which impact on system and workload performance. As we uncover provide the required snapshotting and CoW capabilities for new properties of the popular Docker storage drivers, this is a images. None of these solutions, however, were designed with sobering reminder that widespread use of new technologies can Docker in mind and their effectiveness for Docker has not been often precede their careful evaluation.
    [Show full text]
  • MINCS - the Container in the Shell (Script)
    MINCS - The Container in the Shell (script) - Masami Hiramatsu <[email protected]> Tech Lead, Linaro Ltd. Open Source Summit Japan 2017 LEADING COLLABORATION IN THE ARM ECOSYSTEM Who am I... Masami Hiramatsu - Linux kernel kprobes maintainer - Working for Linaro as a Tech Lead LEADING COLLABORATION IN THE ARM ECOSYSTEM Demo # minc top # minc -r /opt/debian/x86_64 # minc -r /opt/debian/arm64 --arch arm64 LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is MINCS? My Personal Fun Project to learn how linux containers work :-) LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is MINCS? Mini Container Shell Scripts (pronounced ‘minks’) - Container engine implementation using POSIX shell scripts - It is small (~60KB, ~2KLOC) (~20KB in minimum) - It can run on busybox - No architecture dependency (* except for qemu/um mode) - No need for special binaries (* except for libcap, just for capsh --exec) - Main Features - Namespaces (Mount, PID, User, UTS, Net*) - Cgroups (CPU, Memory) - Capabilities - Overlay filesystem - Qemu cross-arch/system emulation - User-mode-linux - Image importing from dockerhub And all are done by CLI commands :-) LEADING COLLABORATION IN THE ARM ECOSYSTEM Why Shell Script? That is my favorite language :-) - Easy to understand for *nix administrators - Just a bunch of commands - Easy to modify - Good for prototyping - Easy to deploy - No architecture dependencies - Very small - Able to run on busybox (+ libcap is perfect) LEADING COLLABORATION IN THE ARM ECOSYSTEM MINCS Use-Cases For Learning - Understand how containers work For Development - Prepare isolated (cross-)build environment For Testing - Test new applications in isolated environment - Test new kernel features on qemu using local tools For products? - Maybe good for embedded devices which has small resources LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is A Linux Container? There are many linux container engines - Docker, LXC, rkt, runc, ..
    [Show full text]