microservices: a security nightmare?
TRANSCRIPT
Microservices –a security nightmare?
GOTO Nights Zürich - March 3, 2016
Maximilian Schöfmann | @schoefmann
Container Solutions Switzerland
Microservices (2016) …
Microservices (2016) …
small, hence many services
Microservices (2016) …
small, hence many services
talking over the network
Microservices (2016) …
small, hence many services
talking over the networkbuilt with different technologies
Microservices (2016) …
small, hence many services
talking over the networkbuilt with different technologies
by autonomous teams with end-to-end responsibility
Microservices (2016) …
small, hence many services
talking over the networkbuilt with different technologies
by autonomous teams with end-to-end responsibilitydoing DevOps and Continuous Delivery
Microservices (2016) …
small, hence many services
talking over the networkbuilt with different technologies
by autonomous teams with end-to-end responsibilitydoing DevOps and Continuous Delivery
using containers
Microservices (2016) …
small, hence many services
talking over the network
built with different technologies
by autonomous teams with end-to-end responsibility
doing DevOps and Continuous Delivery
using containers
Microservices are the result of combining
architectural ideas from lightweight SOA
and Domain Driven Design,
organisational approaches like DevOps
and Agile Software Development, and
technology innovations like Containers
and Programmable Infrastructure
Architecture Organisation
Technology
Monolith
“many small services”
Monolith - method calls
Microservices - talking over the network
Java7(1.7.0_03)
Monolith - few technologies
Microservices - built with different technologies
nodejs0.9
Ruby2.1
Java7
Go1.4
Java8
Security Gates vs…
… autonomous teams with end-to-end responsibility
… autonomous teams with end-to-end responsibility
dedicated security experts vs…
(ISC)2®
doing DevOps
OWASP??
classic “Security Sandwich” vs…
classic “Security Sandwich” vs…
Specification
Implementation Validation
… Continuous Delivery
well isolated “real server” vs…
… using containers
Attack surface - VMs vs containers
XENHypervisor-10^5LOC
LinuxKernel-10^7LOC
Highly coupled services No clear boundaries
Loosely coupled services Clear boundaries
many small services
impact of breach can be contained locally
“Clear service boundaries limit the impact of breaches”
Keep APIs minimal
payment_data
(stateless)
cat_ pictures
(stateless)
user_db
Microservices have their own data store
payment_data
(stateless)
cat_ pictures
(stateless)
user_db
Microservices have their own data store
“Let the need-to-know principle guide your API design”
payment_data
(stateless)
cat_ pictures
(stateless)
user_db
different security levels should require different security
properties in services, e.g. encryption, auth, security testing…
“Classify services into distinct security levels”
API Gateways
APIG
atew
ay
API Gateways
APIG
atew
ay
• Access control
• Rate limiting
• HTTPS termination . . .
API Gateways
APIG
atew
ay
WAF PaymentSvc.
“Isolate services with different security levels through gateways”
Authorization & Authentication
Authorization & Authentication
“Use scalable auth techniques without single points of failure”
Secrets management
vaultproject.io square.github.io/keywhiz
“Manage secrets with special purpose services”
Freeze image for analysis
paymentservice
instance#2
docsuploadservice
instance#1
paymentservice
instance#1
catpictureservice
instance#1
memegeneratorinstance#1
bookmarkmanager
instance#1
paymentservice
instance#1
Or even the running container… (criu.org)
paymentservice
instance#2
docsuploadservice
instance#1
paymentservice
instance#1
catpictureservice
instance#1
memegeneratorinstance#1
bookmarkmanager
instance#1
paymentservice
instance#1
“Leverage container features for forensics”
Scheduling constraints
paymentservice
instance#2
docsuploadservice
instance#1
paymentservice
instance#1
catpictureservice
instance#1
memegeneratorinstance#1
bookmarkmanager
instance#1
“Run services of different security levels on different hosts”
Replace containers on deploy
paymentservice
instance#2
docsuploadservice
instance#1
paymentservice
instance#3
catpictureservice
instance#1
memegeneratorinstance#1
bookmarkmanager
instance#1
“Embrace immutable infrastructure”
“built with different technologies”
nodejs0.9
Ruby2.1
Java7
Go1.4
Java8
Monocultures…
Scanning images at rest
Clair(CoreOS)Nautilus(DockerInc.)
“Scan images already during the build process”
Container technology…
BSDJails2000
2001
VirtuozzoLinux-VServer
SolarisZones2004
LXC2008
2013
Docker
rkt2014
1982
chroot2007
cgroups
Docker security hardening…
container-solutions.com/security
•read-onlycontainers•minimalbaseimages•dropcapabilities•traditionalhardening(AppArmor,SELinux…)
...
“Minimise the attack surface of images and hosts”
Unify & secure deployment methods
Simple to add…
• TLS
• Authentication
• Authorisation
• Logging & Auditing
• Image verification
scp
rsync
git
“Have a single, hardened method to deploy”
…end-to-end responsibility
Gates and Accountability
Security Sandwich and Autonomy
Specification
Implementation Validation
Security Sandwich and Autonomy
Security Sandwich and Autonomy
Trust
IdeafromA.T.KearnyAnalysis
Accountability Expertise
Autonomy&Entrepreneurship
Collaboration&Support
Trust
Security aspects must becomepart of the Definition of Done…
SecDevOps?
SecOps?
DevSec?
TheroleofITArchitectsisalreadychanging
Now,theroleoftheSecurityTeamneedstochange
“Accountability ensures security is built in, not bolted on”
Avg: 103 days to fix a vulnerability
http://darkmatters.norsecorp.com/2015/06/09/security-vulnerabilities-take-average-of-103-days-to-remediate/
CD reduces reaction time
“Leverage Continuous Delivery as a security feature”
Test pyramid
UnitTests
ServiceTests
UItests
fasterfeed
back
from“SucceedingwithAgile”(MikeCohn)
confiden
ce
Security-Test pyramid / AppSec pipeline
staticcodeanalysis
Vulnerability
scanning
E2E
securitytests
fasterfeed
back
confiden
ce
BDD style
continuumsecurity.net/bdd-intro.htmlgauntlt.org
“Have your test pyramid reflect security”
Architecture Organisation
Technology
Architecture
Clearserviceboundarieslimittheimpactofbreaches
Lettheneed-to-knowprincipleguideyourAPIdesign
Classifyservicesintodistinctsecuritylevels,whichmandatedifferentsecurityproperties
Usescalableauthtechniqueswithoutsinglepointsoffailure
Isolateserviceswithdifferentsecuritylevelswithgateways
Managesecretsinspecialisedservices
Technology
Runservicesofdifferentsecuritylevelsondifferenthosts
Leveragecontainerfeaturesforforensics
Embraceimmutableinfrastructure
Scanimagesaspartofthebuildprocess
Haveasingle,hardenedmethodtodeploy
Minimisetheattacksurfaceofimagesandhosts
Organisation
LeverageContinuousDeliveryasasecurityfeature
Haveyourtestpyramidreflectsecurity
Accountabilityensuressecurityisbuiltin,notboltedon
Nightmare?
