Strategy, Planning and Governance forEnterprise Deployments of Containers

Stéphane WoillezTechnical Lead South EuropeDocker Inc.

Hummm, it’s time to think about Enterprise deployment….

• Most internal developers use Docker and want to deliver containers

• Commercial software start to be delivered as container images

• There is an Hybrid cloud initiative

• More than 5 dockerized applications now run in production

• IT needs to lower costs and densify applications in production

• There is a DevOps strategy going on

• The Software Factory thinks about Micro Services and Serverless

The signs that tell it’s time to build an enterprise strategy for containers

2

Agenda of my Enterprise deployment strategy

• Choice of the underlying infrastructure

• Image Governance

• Security of my Docker Platform

• Operations

• Applications Migration

• Conclusion : Wow wow wow, tell me where to start from

Obviously non exhaustive

3

Choice of the underlying infrastructure

Virtualization or bare metal ?What about using Linux Micro DistributionsHow many Docker environments ?Is production more critical than other environments ?

Virtualization or bare metal ?

• Docker works perfectly in both environments• Virtualization :

o Pros : Operations ready, easy backupo Cons : Overhead, Cost

• Bare Metal :o Pros : Efficiency, low cost, simplicityo Cons : I forgot how to manage Bare Metal

• Decision has to be made on different aspects :o Cost or expected TCOo Workload compatibilityo Existing Operational environment

• Advice : Take the hybrid wayo Use virtualization for managerso Use Bare Metal for workers

The cost optimization does not come from where expected… Think densification

5

What about using Linux Micro Distributions ?

• Many Micro Linux distributions exists : o Alpine, CoreOS, Docker LinuxKit, RedHat Atomic,

Ubuntu Core, VMWare Photon, …• Pros :

o Ultra optimized for containers executiono Best host securityo Lower cost

• Cons :o Not a lot of experience in productiono Difficult to have a end to end support yet

• Advice : Take time to deploy in productiono Test Micro Linuxes in non productiono Keep standard distributions for production

Small and strong

6

How many Docker environments ?

• The number of environments and the number of clusters may differ because of multi tenancy

• Many aspects influence the number if environments

o Existing organization

o Security level

o Outsourcing & third party software

o Split between organizations or divisions

• Most users have 2 clusters (production, non-production), others have much more (6-10)

• Advice : Production is important, but Dev is even more, because of its visibility during the Docker project

My Docker cluster is bigger than yours…

Production

Development

BetaIntegration, Test, Sandbox,Preproduction

7

Image Governance

Registry ArchitecturesImages ManagementChange Management

Registry Architectures

• Should I use a general purpose registry, or one designed for containers management ?

o Keep existing general purpose registries

o Don’t miss extra functions of containers registries (ex:DTR brings content trust)

• Should I have separate registries for :

o Production protection : NO

o Physical isolation : YES

o Accepting third party images : MAYBE

o Delivering images to locations : NO

o Application separation : MAYBE

o Managing hybrid deployments : MAYBE

Standalone Deployment

High Availability

Simple Chaining

Complex Chaining

One to rule them all…. Or maybe not

9

Docker images registries : The usual deployment schemes

• Standalone or high availability ?

o The choice depends on the deployment frequency

o Standalone can be ok for production

o In general, high availability is required for dev

• IT provides base images using a central registry

• Managed production is linked to the central registry

• Autonomous clusters can replicate the base images

• For security reasons, a secondary registry is deployed in DMZ for external deliveries

• Access by developers from remote locations can be eased by a network of proxies / cache servers

• Everyone can pull from Central, no one but the CI/CD can push

Central or distributed, or maybe replicated

Central DTR

Production Autonomous Cluster

Local DTR

DMZ DTR

DTR Cache

DTR Cache

DTR Cache

DTR Cache

PUSH

PULL

COMMIT

10

Image Management

• Hub Images or my private images ?

o Allow developers to use hub images locally

o Deny uncontrolled images on clusters

• Build your own base images

o Tar the content of a chroot dir and use “scratch”

o Look for examples in the Docker Hub

• Minimize the number of layers in images using multi stage builds

• Tagging

o LATEST is your enemy in production

o Favor major versions, update using minors

o Some use extra tags like DEV,INTEGRATION...

FROM scratchADD <chroot_dir or tar file> /CMD ["/bin/bash"]

Docker HUB Trusted Registry

Image quality is key to many aspects of Docker : security, efficiency, shareability…

11

Change Management

• Apps in containers are not patched !!!

• Change Management is about:

o Update of the platformo Update of applicationso Update of images

• The update of the platform is not a problem, the orchestrator takes care about availability of Apps

• Same for applications. Rolling updates of Apps is a standard of orchestration

• Triggers of images change management:

o New versions of base OS imageso Updates of middlewares and runtimeso Reaction to the discovery of a vulnerability

Yes, I do not patch, but I need to update

12

Security

Containers are secure. What can we do more?Security of the engineSecurity inside the containerMulti tenancy

State of the union : Containers are secure !

• Isolation of containers with NameSpaces

• Resource Usage Limits with CGroups

• Admin rights control with LibCap

• Kernel protection with AppArmor, SELinux or Seccomp

• Prevent Compromising with immutable image layers

• Limit attack surface with Images built best practices

Readonly

Readonly

Readonly

Install only the required libraries in images

Even the more secured environment, if poorly managed, can be compromised

14

Security of the Engine

• Install & configure kernel protection using AppArmor, SELinux or Seccomp

• Prevent root access to clusters, to ensure no one can disable protection

• Limit the installed packages on host to reduce risk

• Use a tool like DockerBench for Security to assess and fix the configuration of hosts

• On clusters, configure certificates rotation for TLS sessions

Configure, control, and test…

15

Content trust : Run only trusted images

• Clusters should only run trusted images

• Images should pass security validation before been granted for production

• Digital signing of images ensure trust. Engines do not create containers from unsigned images

• Sophisticated signing policies can be used for different purposes :

o Implement a validation chain

o Ensure all security tests have been applied

o Involve the responsibility of image providers

Don’t open the Pandora’s box, unless you know exactly what it contains

16

Detection of intrusions and abnormal activities

• Very early stage. Attacks adapted to containers still to be developed. Risk low for Micro Services Apps

• The security approach depends on the type of containers managed

• For « Virtual Machines » containers

o Well, everything works like in VMs

o Host based Intrusion detection

o Anti malware

• For « Services » containers

o Containers may live for only milliseconds

o Vulnerability assessment BEFORE execution

What the hell are you doing inside my Docker cluster ?

17

Multi tenancy

• Do not mix up platform multi tenancy and application multi tenancy

• Two main usage of Multi Tenancy :o Isolate users/apps from others

o Protect environments from unauthorized users▪ Production vs Other environments

• Several combined technics allows multi tenancy :

o Authentication (not only for users)o Role based access control

o Isolation of compute resources (pros & cons)o Resource usage limits (ensure they are set)

Ensure & control good relationship between neighbors

18

Operations (lot’s of subjects)

Should I manage containers like VMs ?Log, Monitoring, Alert management Backup ManagementChargeback and License Management

Logging, Monitoring, Alerting, Backup, Chargeback & License Management

• They are all important, and need a specific focus• Two approaches are often seen :

o Built-in capabilities of the Docker platformo Integration with existing external systems

• Logging, Monitoring and Alerting are strong requirements of production

• Backup is not always required with containers, due to their stateless nature

• Chargeback is required in mutualized environments, partly built-in partly integrated

• License Management is pretty new and brought by the « Modernization of applications » initiative. It’s a tricky subject as it involves both technical and legal aspects.

Often seen in this order from most to less urgent/required

20

Application Migration

Containers PlaygroundGood candidates to app migrationTrickier apps for containerizationDon’t stop at step 1 of modernization (please!)

Containers, the playground

• Supported platforms : Linux, Windows Server, zLinux, pLinux

• The underlying infra : Bare Metal, Virtualisation, Public clouds

• No Graphical User Interface inside containers (though…)

• Unattended installation

• Check the support of commercial software on https://store.docker.com

• Beware of high end requirements regarding storage performances

Most fairly modern applications can be converted to containers

22

App Modernization is much more than lift and shift

App

• App Modernization with containers requires a bit of refactoring to deliver higher value

• Additional value can be obtained by applying Cloud Principles and Micro Services

• Docker allows the use of an iterative process for modernization

• Deliver quick & visible results with Apps sharing the same components

ExistingApplication

Modern Methodologies

Integrate to CI/CDand automation

system

Convert to a container

Modern Infrastructure

Built on premise, in the cloud, or as part of a hybrid environment.

Modern Microservices

Add new services or start peeling off

services from monolith code base

Don’t use containers for huge monolithic applications, use the technology to fuel your modernization strategy

23

Conclusion

Where to start to build and deliver a CaaS platform…

Start by building the platform, or start with Apps ?

• The Platform approach : Build the enterprise container platform, then onboard applications

• The Apps approach : Migrate applications to collect operational requirements, then mutualize

• A combined approach seems the most appropriate :

o Production requires the availability of a minimum set of operational services

o Success & Adoption are triggered by a critical mass of applications in production, estimated between 3 and 5

o Docker = Dev Ops. A common initiative is needed for Devs and Ops to understand their respective trades and work on a common initiative

A Docker project is a good way to complement a DevOps strategy, and vice-versa

25