ContainerDays NYC 2016: "The Secure Introduction Problem: Getting Secrets Into Containers" (Jeff Mitchell)
Nov. 9, 2016•0 likes•2,424 views
Report
Technology
Slides from Jeff Mitchell's talk "The Secure Introduction Problem: Getting Secrets Into Containers" at ContainerDays NYC 2016: http://dynamicinfradays.org/events/2016-nyc/programme.html#secrets
ContainerDays NYC 2016: "The Secure Introduction Problem: Getting Secrets Into Containers" (Jeff Mitchell)
1. Think Like a Vault Developer:
Secure Introduction & Containers
Jeff Mitchell
HashiCorp
@jefferai
2. ● Understand basic tenets of security, as the Vault team
thinks about them
● Explore properties necessary for secret management and
(initial) secret distribution
Goals
3. ● Understand basic tenets of security, as the Vault team
thinks about them
● Explore properties necessary for secret management and
(initial) secret distribution
Goals
BORING
4. ● Applied security in action: secure introduction, response
wrapping and orchestrators
○ Not a Nomad/Vault talk but will use these as examples
Goals
5. Non-Goals
● Discussion of crypto theory
○ Crypto properties (algorithm selection, etc.) are important for
applied security
○ Can stay high-level
● Comparison of container/hypervisor/OS security
○ Let’s talk Linux/Docker
8. “Security”
● Security is the practice of risk management
○ Deciding which risks can be accepted and which cannot
○ Guarding against violations of norms
● Risk increases with system complexity
○ More points of failure, confusion, ingress and egress
10. “Secret”
● A secret is something that will elevate your risk if exposed
to unauthorized entities
● Undesired consequences are harm
○ Unauthorized data access
○ Identity spoofing
○ Private data egress
○ Regulatory fines
11. Exposure
● An exposed secret
○ Elevates risk
○ May cause harm
● An exposed secret is a threat
12. Secrets vs. Identifiers
● Some things that can be disclosed are identifiers
○ Username (identifier) vs. Password (secret)
○ TLS certificate (identifier) vs. TLS key (secret)
○ GitHub user name (identifier) vs. API key (secret)
● Identifiers aren’t completely risk-free
○ Have chosen to ignore that risk
13. What is “Trust”?
● A trusted entity is one that will not divulge the secrets it
has access to
● Modeling trusted entities is a companion to modeling
threats
● Two concepts
14. Circle of Trust
Entities we trust with any secret. For this talk:
RAM
root
Secret
Management
ToolEmployees?
CPU
Cloud?
15. Circle of Trust
Things not in circle of trust:
Persistent
Storage
Random
Users
General
apps/services
NSA
Random
Wi-Fi Hotspot
Your Mother’s
Notepad.txt Employees?
CPU
Cloud?
RAM
root
Secret
Management
Tool
CPU
Cloud?
Employees?
16. Circle of Trust
Only allowed long-term storage is in circle of trust
Persistent
Storage
Random
Users
General
apps/services
NSA
Random
Wi-Fi Hotspot
Your Mother’s
Notepad.txt Employees?
CPU
Cloud?
RAM
root
Secret
Management
Tool
CPU
Cloud?
Employees?
17. Chain of Trust
● The set of links (e.g. network hops) that any particular
secret travels through from source entity A to destination
entity B
● Source/destination must be in circle of trust
18. Links
● Any link in a chain of trust is a potential access
point/interception point
○ Accidental logging
○ Exploitation by attacker
○ Lookup by operator
○ Conspiracy of One/Compromised employee
○ Employee Post-It™
19. Problem Space
● We can now establish a problem space:
○ Managing secrets in a given environment means establishing trust
chains in the environment
● Links in the chains have associated risk
○ Minimize hops and minimize risk-per-link
20. Problem Space
● In other words: figuring out how to securely get a secret
from producer to consumer
21. Problem Space
● In other words: figuring out how to securely get a secret
from producer to consumer
DUH