Security Containers

1. Background on Virtualization

1.1. Full virtualization

1.2. Para virtualization

1.3. Kernel or container based virtualization

2. Why containers?

2.1. Why containers over full/para?

2.2. When containers over full/para?

3. Evolution of containers

3.1. Solid tech. since 1982

3.2. 1982 - chroot

3.3. 1998 - FreeBSD Jails

3.4. 2004 - Solaris Zones

3.5. 2005 - OpenVZ

3.6. 2008 - LXC

3.7. 2013 - Docker

4. Properties of container

4.1. Isolation

4.1.1. File system

4.1.2. I/O

4.1.3. Network

4.1.4. CPU

4.1.5. Memory

4.2. Privileges

4.2.1. Can I give someone root?

4.3. Speed

4.3.1. How close to bare metal?

4.4. Efficiency

4.4.1. Copy on write

4.4.2. Resource pooling

5. ...Enter Snap CI

5.1. Hosted continuous integration platform

5.2. Running untrusted code thousands of times a day

5.3. Users demand extreme speed

5.3.1. Must be faster than my build box

5.3.2. Builds must start-up in a flash

5.4. Needs isolation

5.4.1. Builds cannot see each other

5.4.2. Builds cannot affect each other

5.4.2.1. Network

5.4.2.2. Memory

5.4.2.3. Disk

5.4.2.4. I/O

5.4.2.5. CPU

5.5. Users need privilege

5.5.1. I want to test my Chef code. Need root.

5.5.2. I want to install latest gcc. Need root.

5.5.3. I want to start a service without changing init scripts. Need root.

6. LXC

6.1. Better upstream support.

6.2. Namespaces baked into Kernel

6.3. Unprivileged containers can help with escalated privileges inside container

7. Docker

7.1. Much more efficient - Copy-on-write

7.2. Abstraction over container tech. via libcontainer

7.3. No user namespace support

7.4. Docker daemon runs as root

7.5. Better suited to be application containers

8. We chose OpenVZ

8.1. Circa mid 2012

8.2. Why OpenVZ over LXC?

8.3. Why OpenVZ over Docker?

8.4. Linux kernel namespaces vs OpenVZ namespacing

8.5. Full isolation

9. First cut: dedicated on-demand containers

9.1. Good

9.1.1. Isolated

9.1.2. Users can scale to n-containers

9.1.3. Bespoke containers. Can create per user demand.

9.2. Bad

9.2.1. Very slow build startup

9.2.2. Very poor utilization

9.2.3. Complex orchestration

9.2.4. Very large inventory of containers with poor utilization

10. Next: shared containers

10.1. Container inventory with software pre-installed

10.2. Containers always-on

10.3. Dispatch build to first available container

10.4. How we ensure clean slate between runs

10.5. Very efficient

10.6. Maintain isloation via logic in app code + containers

10.7. Don't leave running processes behind

11. Finally: shared containers with full root

11.1. Users can do whatever they want inside sandbox

11.2. OpenVZ ploop snapshots

11.3. Restore filesystem to pristine state

11.4. Back to bespoke. Users can tune their containers to their liking.

12. App code to manage OpenVZ

12.1. vzctl

12.2. shell

12.3. Unix pipes and signals

12.4. Caching

12.5. Storing parts of the container file system safely

12.6. Artifacts

12.7. Fast dispatch

13. What's next with container tech.

13.1. When are user namespaces landing

13.2. When can we have full isolation with Docker?

14. Takeaway

14.1. Container based virtualization is fast and efficient

14.2. Containers are useful in production. Not just limited to testing.

14.3. Speed, efficiency and security are all possible if you choose the right container tech. for your problem.

14.4. Essentially problem/container tech. fit.