Containers for Lawyers Richard Fontana

Richard Fontana

Senior Commercial Counsel

Red Hat

CONTAINERS FOR LAWYERS

© 2016 Red Hat, Inc. License: . Modified versions must remove all Red Hat trademarks.CC BY-SA 4.0

1

OUTLINEWhat's interesting about containers

Historical contextBrief overview of Docker-style containers

Some interesting legal issuesContainers and security

2

HISTORICAL CONTEXT

3

Mainframe era Unix era Linux era

Integratedproprietary

HW/SW stack

ISVecosystem

tied tovendor HW

SYSTEM VENDOR LOCKIN AND THE RISE OF LINUX

Integratedproprietary

HW/OS stack

Choice of HW

Vendor-neutral

applicationruntime

Open ISVecosystem

Operating system: infrastructure vs. application runtime

4

LINUX APPLICATION RUNTIME

Multiple adminscompile from

source onproduction host

Archives ofprecompiledbinaries; nodependency

management

Sophisticatedbinary

packagemanagement

systems

Characteristics of modern Linux distribution

Curated stacks from trusted sourceAutomatic management of installation, updates, removals, dependenciesSystem library paradigm (good for security)Highly modular component-level packaging

5

APPA

APPC

APPB

HARDWARE

OS & SHAREDSERVICES

BINS/LIBS

All applications share one big runtime tied to distro release cycle

TRADITIONAL LINUX APPLICATION DEPLOYMENT

DISTRO

6

DRAWBACKS TO LINUX DISTRO/RUNTIME MODEL

Benefits of multiple instances/versions of stack componentsSeparately-packaged stack components may change as you move fromdevelopment to testing to production"One big runtime" can be too inflexibleDifficult to manage shared dependencies - instability

7

APPA

SERVER

HOST OS

HYPERVISOR

HYPERVISOR VIRTUALIZATION

BINS/LIBS

GUESTOS

GUESTOS

GUESTOS

Isolation of application/runtime fromhardwareApplication-defined guest environment

Install the packages and versions you needto run

More flexibility but a lot of overhead perapplicationManagement of host and VM layers iscomplex

APPB

8

BINS/LIBS

APPC

BINS/LIBS

THE RISE OF DEVELOPERS

"Software is eating the world"Software is increasingly strategic across industriesBusiness differentiation driven by softwareDevelopers gain influence over what software they can use and how todeploy it

9

DEVELOPER PREFERENCES

Huge complex open source stacks, impossible to fully package in a distroLatest versions can't be provided by distros; developers go direct toupstreamDevelopers compile from source or use upstream prebuilt binariesSee value in distro only at the foundational level

10

BRIEF OVERVIEW OF DOCKER-STYLECONTAINERS

11

CONTAINERS (OPERATING SYSTEM VIRTUALIZATION)SVC

A

HARDWARE, VIRT CLOUD

HOST OS, SHARED SERVICES

HYPERVISORBINS/LIBS

SVCB

BINS/LIBS

SVCC

BINS/LIBS

Multiple userspace stacks (application + runtime dependencies) run inisolation, sharing kernel; no hypervisor/emulation layer Linux containers - leverage kernel subsystems

cgroups: amount of resources process group can havenamespaces: application appears to have entire server

Compared to VMs: greater density and elasticity, more efficient, lowoverhead, speed of starting/stopping instances

12

DOCKER-STYLE CONTAINERS

Docker project: easy-to-use approach for running and distributingcontainerized applications based on lightweight, layered imagesportable across hostsEncourages designing applications as microservicesContainer image: format in which content can be transferredContainer: instance of a running imageContainers are generally treated as disposable (can be stopped andstarted but not generally relied on for persistence)Registry: service for storing and distributing repositories of images

Enables separation of system runtime from application runtime; systembecomes multiple instance, multiple version

Division of organizational responsibility: developers control inside ofcontainer, ops controls where the container runs

13

LAYERED IMAGE MODELImage is a union of uniquely-identified read-only filesystem layersstacked on top of each otherHigher level of data abstraction than a disk/VM imageA layer modifies the result of the layers below it

Base layer - generally a stripped-down Linux distroSubsequent layers can add, modify or delete from files laid out bylower layers

Each layer is a small set of files (image manifest, configuration file,tarball)Layered approach enables sharing of common container content -reduces time to build/download images, space to store images

14

DOCKER HUB

15

DOCKER HUB

16

DOCKERFILE

FROM tozd/runit

EXPOSE 27017/tcp

VOLUME /var/lib/mongodbVOLUME /var/log/mongodb

RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10 && \ echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' > /etc/apt/sources.list.d/mongodb.list && \ apt-get update -q -q && \ apt-get install --yes --force-yes mongodb-org

COPY ./etc /etc

Automates building of a container image

17

INTERACTION AMONG CONTAINERS

Interaction between software in separate containers is interactionbetween separately executing processes

Network connections, shared storage, Unix sockets

Applications may be composed of many interacting containers running onmultiple hosts - orchestration with tools such as Kubernetes

Load balancing, scheduling, scaling, failover, maximizing resourceusage

Multi-container application coordination analogous to past transition topackage management

New models for packaging complex applications - Nulecule/AtomicApp

18

CONTAINER-OPTIMIZED OPERATING SYSTEMS

Application runtimes are in containers, so host system can be reducedto what's needed to run containersMinimal feature set enables fast boot, smaller storage requirements,and lower CPU consumptionCoreOS, Atomic Host, RancherOS, Snappy Ubuntu Core

19

STANDARDIZATION/INDUSTRY CONSORTIA

20

SOME LEGAL ISSUES

21

SINGLE CONTAINER IMAGE AND COPYLEFT SCOPE

Base images necessarily contain a lot of GPLv2/GPLv3 codeLinux distros are sometimes conceptualized as GPLv2-licensedGPLv2: mere aggregation clause; GPLv3 "Aggregate"Container images do not raise any special copyleft scope issue

Container image is a packaging format using established packagingmechanisms (tar format, etc.)Share characteristics with RPMs, VM imagesNo technical/legal basis for analyzing container images differentlyfrom past Linux stack distribution media for purposes of GPL scope

Nature of combination of software inside a container image does notraise unique GPL scope issue

22

MULTIPLE CONTAINERS AND COPYLEFT SCOPE

Can software in one container fall within copyleft scope of software inanother container?

Not likely, though decomposition into multiple containers is notguarantee of absence of copyleft issueIf software inside a container is generally mere aggregation, software inseparate interacting containers must also be mere aggregationContainerization provides an addition argument for 'separateness' -makes technical boundaries between components more apparentFSF: process boundary relevant for GPL scope

Software in separate containers always runs in separate processesMulti-container applications more analogous to Unix pipes than tostatic linking

23

AGPL AND DOCKER CONTAINERS

Residual concern around notion of unbounded scope of AGPL inconventional Linux server settingPractical uses of containers generally involve some sort of web/cloudtechnologyIsolated nature of container image should diminish force of overbroadreading of § 13 "modify" trigger and Corresponding Source scope

24

CONTAINER IMAGES AND LICENSE COMPLIANCE

“ Isn't copyleft practically dead in a containerized world because nearlyeveryone publishes containers without corresponding source code and

build scripts, and gets away with it?

Mostly concerns Docker Hub (and GitHub) as mode of binary distributionLogically not limited to GPL/copyleft (or open source in general)Any ecosystem-wide noncompliance likely no worse than what we see inother binary component distribution ecosystems (e.g. Maven Central)

25


GPLv2 § 3: "If distribution of executable or object code is made by offeringaccess to copy from a designated place, then offering equivalent access tocopy the source code from the same place counts as distribution of thesource code, even though third parties are not compelled to copy thesource along with the object code."

GPLv3 § 6(d): "If the place to copy the object code is a network server, theCorresponding Source may be on a different server (operated by you or athird party) that supports equivalent copying facilities, provided youmaintain clear directions next to the object code saying where to find theCorresponding Source."

26


Dockerfiles do not generally provide reproducibility; not designed as a means forGPL source code complianceMany Docker Hub images have no published DockerfileIn general, no reliable way to know contents or provenance of image (other thanto pull and do inspection and forensic analysis)No known Docker Hub image approaching strict compliance with GPLv2 §3/GPLv3 § 6Exposes general problems in mapping open source license conditions to modernmodes of distribution

27

Use of immutable union filesystem layers with unique IDs presentsopportunity to facilitate improved license compliance, provenance tracking

Immutability - rebuilt container image will have a different name andthus will be a different layer - provides unambiguous way to refer toeach file

Allows unambiguously associating separate metadata with a layer, suchas license-related information


28

DOCKER HUB AND TRADEMARK ISSUESCanonical IP Policy and Ubuntu base images

"Any redistribution of modified versions of Ubuntu must be approved,certified or provided by Canonical if you are going to associate it with theTrademarks. Otherwise you must remove and replace the Trademarks andwill need to recompile the source code to create your own binaries."

29

CONTAINERS AND SECURITY

30

As IT systems get more complex (numbers of actors and decompositionof applications), security becomes an increasingly difficult problemSecurity requires you to only use content you trustEarlier approach was to standardize your operating environment

Conflicts with desire for agility, developer autonomyNo longer scales

Security is temporal (trust decays over time)


31


Containers both require and facilitate an automated approach tohandling securityTools can prevent starting/building with a container that violates securitypolicyVerify where the container image comes fromVerify what's inside the container imageOver 30% of Docker Hub images contain "high priority" securityvulnerabilities (Banyan 2015)Red Hat Atomic scan: pluggable scanning interface for containers

OpenSCAP container scanner (use images from trusted vendor butvalidateBlack Duck - validate untrusted content downloaded by developers

32

THANK YOU

@richardfontana

[email protected]

CC BY-SA 3.0 Unported: Still image from Tom Callaway, This is how you FAIL https://www.youtube.com/watch?v=fRk97h1FLow.

The Red Hat Shadowman logo, the Red Hat logotype and the Project Atomic logo are trademarks of and copyrighted by Red Hat, Inc. and are not

licensed.

Inclusion of all other third-party images based on fair use or noncopyrightability rationales.

33

Technology

Containers for Lawyers Richard Fontana