A DevOps State of Mind:
Continuous Security with
DevSecOps + Containers
Chris Van Tuin
Chief Technologist, NA West / Silicon Valley
cvantuin@redhat.com
“Only the Paranoid Survive”
- Andy Grove, 1998
Retail Finance Media
Transportation
?
?
SOFTWARE DISRUPTS BUSINESS
DEV QA OPS
Walled off people, walled off processes, walled off technologies
“THROW IT OVER THE WALL”
Time to Value
Months to
Years
Weeks and
Months
Days
and
Weeks
IT MUST EVOLVE TO STAY AHEAD OF DEMANDS
DEV QA OPS
Open organization + 

cross-functional teams
Software factory
automation
Linux + Containers
IaaS
Orchestration
CI/CD
Source Control Management
Collaboration
Build and Artifact Management
Testing
Frameworks
OpenSource
CI/CD pipelines
with feedback
Culture Process Technology
+ +
BREAKING DOWN THE WALLS WITH DEVOPS
DEV QA OPS
SECURITY IS AN AFTERTHOUGHT
| SECURITY |
“Patch?
The servers are behind the firewall.”
- Anonymous (far too many to name), 2005 - …
http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/
DevSecOps
End to End Security
+ +
SECURITY
DEV
QA OPS
Linux + Containers
IaaS
Orchestration
CI/CD
Source Control Management
Collaboration
Build and Artifact Management
Testing
Frameworks
OpenSource
Culture Process Technology
APPLICATION DELIVERY VIA CONTAINERS
docker.io
RegistryPrivate
RegistryRed Hat
Certified
FROM fedora:latest
CMD echo “Hello”
Build file
Physical, Virtual, Cloud
Image Container
Build RunShip
CONTAINERS: BUILD, SHIP, RUN
Scheduling Monitoring
Persistence
DiscoveryLifecycle & health
Scaling Aggregation Security
MORE THAN CONTAINERS…
DevSecOps
End to End Security
+ +
<——————— SECURITY ———————>
DEV
QA OPS
4
● Are there known vulnerabilities in
the application layer?
● Are the runtime and OS layers up
to date?
● How frequently will the container
be updated and how will I know
when it’s updated?
CONTENT: EACH LAYER MATTERS
CONTAINER
OS
RUNTIME
APPLICATION
Are there known vulnerabilities 

in each application layer?
Are the runtime and OS layers 

up to date?
How frequently will the container
be updated and how will I know
when its updated?
IS THE CONTAINER ENVIRONMENT SECURE?
Is the image from a trusted source?
Can I quickly deploy a security update at scale?
Is my multi-tenant host secure?
Container
host
Network
isolation
Storage
API & Platform
access
Monitoring &
Logging
Federated
clusters
Registry
{}
Builds CI/CDImages
SECURING CONTAINERS
CONTAINER HOST SECURITY
RHEL Kernel
Hardware (Intel, AMD) or Virtual Machine
Containers ContainersContainers
Unit File
Docker
Image
DOCKER CLI
SYSTEMD
Cgroups Namespaces SELinux
Drivers
CONTAINERS ARE LINUX
Hardware (Intel, AMD) or Virtual Machine
Containers ContainersContainers
Unit File
Docker ImageKUBERNETES / DOCKER
SYSTEMD
Cgroups Namespaces SELinux
Drivers
Best Practices
• Don’t run as root
• Limit SSH Access
• Use namespaces
• Define resource quotas
• Enable logging
• Apply Security Errata
• Apply Security Context
and seccomp filters
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html
seccomp
CONTAINER HOST SECURITY
CONTAINER IMAGE SECURITY
4
● Are there known vulnerabilities in
the application layer?
● Are the runtime and OS layers up
to date?
● How frequently will the container
be updated and how will I know
when it’s updated?
CONTENT: EACH LAYER MATTERS
CONTAINER
OS
RUNTIME
APPLICATION
CONTENT: EACH LAYER MATTERS
AYER MATTERS
CONTAINER
OS
RUNTIME
APPLICATION
JAR CONTAINER
A CONVERGED SOFTWARE SUPPLY CHAIN
code config data
Kubernetes
configmaps
secrets
Container
image
Traditional 

data services,
Kubernetes 

persistent volumes
TREAT CONTAINERS AS IMMUTABLE
IMAGE SIGNING
Validate what images and version are running
CONTAINER REGISTRY SECURITY
64% of official images in Docker Hub 

contain high priority security vulnerabilities
examples:
ShellShock (bash)
Heartbleed (OpenSSL)
Poodle (OpenSSL)
Source: Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities, Jayanth Gummaraju, Tarun Desikan, and Yoshio Turner, BanyanOps,
May 2015 (http://www.banyanops.com/pdf/BanyanOps-AnalyzingDockerHub-WhitePaper.pdf)
WHAT’S INSIDE THE CONTAINER MATTERS
PRIVATE REGISTRY
CI WITH CONTAINERS
CI/CD with Security
FROM fedora:latest
CMD echo “Hello”
Build file
Build
Best Practices
• Treat as a Blueprint
• Don’t login to build/configure
• Version control build file
• Be explicit with versions, not latest
• Each Run creates a new layer
BUILDS
Security
CONTINUOUS INTEGRATION WITH SECURITY SCAN
CUSTOM SUPPLY CHAIN
Compliance and Vulnerability Audits
with OpenSCAP
AUTOMATED SECURITY SCANNING with OpenSCAP
ReportsScan
SCAP Security
Guide
for RHEL
CCE-27002-5
Set Password Minimum
Length
Content
Scan physical servers, virtual machines, docker images and containers

for Security Policy Compliance (CCEs) and known Security Vulnerabilities (CVEs)
Standard Docker Host Security Profile
Java Runtime Environment (JRE)
Upstream Firefox STIG
RHEL OSP STIG
Red Hat Corporate Profile for Certified Cloud Providers (RH CCP)
STIG for Red Hat Enterprise Linux 6, 7 Server
STIG for Red Hat Virtualization Hypervisor
Common Profile for General-Purpose Debian Systems
Common Profile for General-Purpose Fedora Systems
Common Profile for General-Purpose Ubuntu Systems
Payment Card Industry – Data Security Standard (PCI-DSS) v3
U.S. Government Commercial Cloud Services (C2S)
CNSSI 1253 Low/Low/Low Control Baseline for Red Hat Enterprise Linux 7
Criminal Justice Information Services (CJIS) Security Policy
Unclassified Information in Non-federal Information Systems and Organizations (NIST 800-171)
U.S. Government Configuration Baseline (NIAP OSPP v4.0, USGCB, STIG)
Security Policies in SCAP Security Guide (partial)
SECURITY POLICY REPORT
SECURITY POLICY REMEDIATION
SECURITY VULNERABILITY REPORT
CD WITH CONTAINERS
CD with Security
CONTINUOUS DEPLOYMENT WITH CONTAINERS
CONTINUOUS DELIVERY DEPLOYMENT STRATEGIES
DEPLOYMENT STRATEGIES
• Blue / Green deployment
• Rolling updates
• Canary deployments
• A / B testing
Version 1
BLUE / GREEN DEPLOYMENT
Route
Version 1
BLUE / GREEN DEPLOYMENT
Version 1.2
Version 1 Tests / CI
BLUE / GREEN DEPLOYMENT
Version 1.2
Version 1 Version 1.2
BLUE / GREEN DEPLOYMENT
Route
Version 1.2
Version 1
BLUE / GREEN DEPLOYMENT
Rollback
Route
Version 1.2
Version 1 Version 1Version 1
Version 1.2
`
Tests / CI
ROLLING UPDATES with ZERO DOWNTIME
Deploy new version and wait until it’s ready…
Version 1 Version 1 V1.2
Health Check:
Readiness 

Probe
e.g. tcp, http, script
V1
Each container/pod is updated one by one
Version 1.2
50%
Version 1 V1 V1.2
Each container/pod is updated one by one
Version 1.2Version 1.2Version 1.2
100%
Container
host
Network
isolation
Storage
API & Platform
access
Monitoring &
Logging
Federated
clusters
Registry
{}
Builds CI/CDImages
SECURING CONTAINERS
Deployment
Frequency
Lead
Time
Deployment

Failure Rate
Mean Time
to Recover
99.999
Service
Availability
DEVSECOPS METRICS
Compliance
Score
THANK YOU
linkedin: Chris Van Tuin
email: cvantuin@redhat.com
twitter: @chrisvantuin

DevOpsDaysRiga 2017: Chris Van Tuin - A DevOps State of Mind: Continuous Security with DevSecOps + Containers