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
ApexGoSparta
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
- Publicly accessible url https://docker.vineapp.com
- Micro-Segmentation: private subnet, sec groups
- Deprecated Docker v1 registry with no security
- Governance and audit of software versions
- Auth setup or hosted private registries
- API and 3rd Party key baked into code
- basic 12factor - separation of code and config
- secrets management
- 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
- Alpine harden gist: jumanjiman/harden.sh
- replace root, restrict ssh & perms,
- remove home, cron, sys cmds
- Code sample: littlebaydigital/docker-alpine-hardended
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
- General Security
- Five Security Conerns when using Docker - Oreilly
- Are containers really secure? - Dan Walsh
- Docker and High Security Microservices - InfoQ
- Minimal OS and Container
- Comparision of Minimal Docker OS - Inovex
- Minimal Docker Containers for Go Applications - Codeship
- Vendors
- Docker in Production is Too Easy - Apcera
Nano-Segmentation
By Yun Zhi Lin
Nano-Segmentation
A Docker Security Journey
- 3,452