This presentation was a discussion on how bringing container technology should be addressed with regards to security. It is focused on setting expectations that can achieve success when rolling out a new platform in enterprise environments.

1. Practical Approaches to
Container Security
Shea Stewart • shea.stewart@arctiq.ca
October 18 2017

2. An Open
Discussion
Container Platform Security
Developer Security
Pipeline Security

3. //container platform security

4. Container Platform Security
● Involve Everyone - DevSecOps (or whatever)
● Context is Everything - Environment Specifics
● Exceptions Are Not be the Norm

5. Container Platform Security
DO
● Assume there is a security sign-off
● Reason with design decisions that
promote enhanced security
● Publish all security considerations
● Automate security configurations
● Monitor and alert on security violations
● Provide varying levels of
“experimentation” and “production”
resources
DON’T
● Design in a vacuum
● Make assumptions
● Presume the platform “includes
all security”
● Ignore the requests of security
related team members
● Permit privileged access instead
of educating users
● Allow unverified images to run

6. //developer security

7. Development Security
● Reduce Friction - Quick and Easy Tooling
● Replicate Production - Local Environment Tooling
● Design for Security - Non-Risky User and FS Permissions

8. Development Security
DO
● Relax security to learn, but tighten to
deploy
● Use local tools and automation to
pre-scan images
● Document security related
configurations
● Share & socialize security related
learnings
● Work with build teams to streamline
base images
DON’T
● Ask for, or expect, security
exceptions
● Assume the new technology will “get
by” old security policies
● Create custom images for every new
app or build
● Run apps as or containers as root
● Run multiple applications in a
container

9. //pipeline security

10. Pipeline Security
● Shift Left
● Automate All the Things
● Notify All of the Users
● Share and Socialize

11. Pipeline Security
DO
● Include non-intrusive security
scanning as a regular testing process
● Replicate pipeline configuration
locally (within reason)
● Run multiple scanning tools (defense
in depth)
● Aggregate results and review as a
team
DON’T
● Wait for security scans to be run
post-release
● Throw scan failures “over the wall”
● Stop improving and optimizing the
pipeline
● Manually configure pipelines

12. Be Curious
Ask Questions
Promote Security
Show Off
Quick list of some helpful tools:
- Container Platform
- Docker & ‘oc cluster up’ or CDK
- Developer
- openscap/atomic scan
- sysdig inspect
- IDE plugins - foritfy, owasp, etc.
- Pipelines
- Docker & CI Containers (ie.
Jenkins)
- Blackduck, sonarqube, jfrog x-ray,
owasp zap, etc.