The popularity of containers has driven the need for distributed systems that have the ability to manage resources, place workloads and adapt to faults. These so-called Container Orchestrators have seen a rise in popularity in the enterprise that is reminiscent of the early container adoption. Open-source projects such as Docker Swarm, Kubernetes and Marathon make it easy for anyone to manage their container workloads using their cloud-based or on-premise infrastructure Unfortunately, a lot of these orchestrator systems have not been architected with security in mind. In particular, compromise of a less-privileged node usually allows an attacker to escalate privileges to either gain control of the whole system, or to access resources it shouldn't have access to. Given the popularity of containers in the enterprise, it is critical that we start designing orchestrators that are designed with security in mind, and follow the principle of least-privilege, where any participant of the system only has access to the resources that are strictly necessary for its legitimate purpose. No more, no less.

1. Orchestrating Least Privilege

2. ~2000 Today

3. What is an Orchestrator?

4. What is an Orchestra?

10. SWARM

11. Job of a Conductor
- Casting
- Assign sheet music
- Unify performers
- Set the tempo

12. Job of an Orchestrator
- Node management
- Task assignment
- Cluster state reconciliation
- Resource Management

13. What is a Least Privilege
Orchestrator?

14. What is Least Privilege?

16. A process must be able to access only
the information and resources that are
necessary for its legitimate purpose.
Principle of Least Privilege

17. An Orchestrator that follows the
principle of least privilege in the
strictest manner possible.
Least Privilege Orchestrator

18. Why Least Privilege?

20. Cluster
Internet

22. Cluster
Internet
A

24. M
M M
AA A

26. M
M M
WW W

28. M
M M
WW W

29. How far away are we
right now?

31. How do we achieve Least
Privilege Orchestration?

32. Mitigating External Attacker
web:
image: web-app
expose: 443
links:
- redis
redis:
image: redis

33. Mitigating Internal Network Attacker
[ { "permission":
{ "method": "GET", "resource": "/user" },
"allow": ["web", "fulfillment", "payments"] },
{ "permission":
{ "method": "POST", "resource": "/user" },
"allow": ["signup", "web"] },
{ "permission":
{ "method": "DELETE", "resource": "/user/.*" },
"allow": ["web"]
}]

34. Mitigating MiTM Attacker
rails-app:
image: rails-app
links:
- mysql
mysql:
image: mysql
MTLS

35. Mitigating Malicious Worker
Push
Worker
Manager
WorkerWorker

36. Mitigating Malicious Manager
Worker
Manager
WorkerWorker
web:
image: web-app
expose: 443
links:
- redis
tls-auth:
- OU: api-client
redis:
image: redis
web:
image:
web-app
expose:
443
links: web:
image:
web-app
expose:
443
links:
web:
image:
web-app
expose:
443
links:

37. SWARM

39. Mutual TLS by default
• First node generates a new
self-signed CA.

40. Mutual TLS by default
• New nodes can get a
certificate issued w/ a
token.

41. Mutual TLS by default
• Workers and managers
identified by their
certificate.

42. Mutual TLS by default
• Communications secured
with Mutual TLS.

44. Secrets

45. Secrets

46. Secrets
External
APP

49. Thank you