Nano Segmentation

A Docker Security Journey

Sydney Docker Meetup August 2016

About Me

  • amaysim Micro(Nano)services Lead

  • 3 years Dockering, Docker Cloud Early Adoptor, Rancher Cowboy

  • proudly decoupled services for foodtech, fintech, proptech

  • shamefully coupled ESBs together for enterprises

  • github: https://github.com/yunspace

  • twitter: @yunzhilin

amaysim Microservices Journey

  • Simplify Monolith systems across 100+ autoscaled EC2
  • DevOps --> NoOps
  • Docker, Rancher OS, Cattle
  • GoLang backend services,
  • Ruby frontend (mostly)
  • GoLang Serverless Lambda using Apex GoSparta

Nano What?

Why Does it matter?

Static Defence

Nano How?

Nano What?

Micro-Segmentation

  • is a security technology that breaks the data center into logical elements and manages them with

high-level IT security policies.

  • AWS Security Groups is a great example

Nano-Segmentation

  • Evolving the principles of Micro-Segmentation further 
  • Network Isolation at the Application and Container level
  • Originally used by Illumio at RSAConf 2015 for App and Processes
  • Further popularised amongst Containers world by Apcera

Segmentation and Overall Security

  • Network Segmentation applies during runtime
  • Build time security is equally important
Buildtime Security
Trust Docker Content Trust, Vulnerability Scan
Attack Surface & Hardening Micro: RancherOS, CoreOS, SELinux
Nano: Scratch, Alpine
Runtime Security
Minimal Privilege Docker 1.10 User Namespace, Secrets Management
​Security Profile Docker 1.10 SecComp, AppArmor
Networking Micro: ​VPC, Security Group, Route Table, Firewall
Nano: Overlay/Isolated Network, Links
Limit Resources cgroup

Docker Production Journey

Vanilla Docker Vendors**
autoscaling* in scope? ECS, K8 HPA, Microscaling
nano-segmentation* Docker Networks apcera, twistlock, aqua***
security 1.10 updates apcera, twistlock, aqua***
visualisation/
metrics/no-ops
docker cloud,
docker data centre
rancher, apcera, K8 ui, prometheus, sysdig
orchestration swarm, machine cattle, apcera, ECS, K8
stack compose rancher-compose, K8 pods
container docker rkt

* autoscaling and nano-segmentation seem to be the final frontiers in Docker productionisation

** vendor list are purely based on personal experience. K8 variants such as Deis are excluded

*** Currently trialing both Twilock and Aqua

Why does it matter?

Because

  • Micro-Segmentation alone is insufficient to secure Containerised Microservices infrastructure. 
  • Impacts IT governance and compliance (PCI, Bassel etc)
  • Challenge is to set empowering policies, not hinderance that leads to Shadow IT complex

Vine.co Hack

  1. Publicly accessible url https://docker.vineapp.com
    • Micro-Segmentation: private subnet, sec groups
  2. Deprecated Docker v1 registry with no security
    • Governance and audit of software versions
    • Auth setup or hosted private registries
  3. API and 3rd Party key baked into code
    • basic 12factor - separation of code and config
    • secrets management
  4. We don't know if there were further vulnerabilities within the running containers: Unsecure or exposed docker port, Host privileges, SSH, DB access

Static Defence

Built into the Build Pipeline

Minimise Attack Surface

Host OS - Minimal distro, limit access to system containers

Minimise Attack Surface

Container base image - Alpine or Scratch

FROM scratch

WORKDIR /app
COPY bin/the-hoff /app

EXPOSE 8080
CMD ["./the-hoff"]

Scan Vulnerabilities

Harden What's Left

FROM alpine:3.4

# download harden script from github
ADD https://raw.githubusercontent.com/LittleBayDigital/docker-alpine-hardened/master/harden.sh && \
  /usr/sbin/harden.sh

# run harden script passing in a desired non-root user
RUN chmod u+x /usr/sbin/harden.sh && \
  /usr/sbin/harden.sh

# declare the non-root user 
USER user
$ docker run -ti --rm alpine-hardened id
uid=1000(user) gid=1000(user)

Nano How?

runtime implementation

Runtime Tools and Practices

  • Use TLS, don't expose docker port, registry, anything
  • SecComp and AppArmor profiles
  • Limit CPU and Memory suing CGroup
  • Enable User Namespace
  • Avoid Privileged Containers or specify exact Capabilities
  • Avoid or isolate mounting /var/run/docker.sock (janitor, builders)
  • Multi-orchestrators: Prod and Non-Prod

Overlay Network

  • Form multi-host clusters within the same VPC or across multi-cloud
  • By default all services across all stacks are discoverable
  • Segments clusters, not applications 

Isolated Network

  • can be used to segment applications
  • but one network per application segment?
# create isolated_nw first
docker run --network=isolated_nw -itd --name=nightrider --link kitt:2000 the-hoff

Apcera Platform

// image white listing
job::/sandbox/user {
  { docker.allow "https://.../trust/good:latest" } 
}

// enforce versioning 
on job::/prod {
  if (dependency equals runtime.ruby) { 
    package.lock "/apcera/pkg/runtimes::ruby-2.3.1" 
  } 
}
// linking job A to job B
job::/sandbox/a {
    if (targetJob nameMatch "job::/sandbox/b") {
        permit link
    }
}
job::/sandbox/b {
    if (sourceJob nameMatch "job::/sandbox/a") {
        permit link
    }
}

TwistLock

Aqua

Wishful Ideal Solution

  • Policy with minimal DSL or manual networks creation
  • Non-Intrusive Container based plugin
  • Docker and Compose compliant
  • Leverage Compose Links

Q's and Further Readings

Nano-Segmentation

By Yun Zhi Lin

Nano-Segmentation

A Docker Security Journey

  • 3,452