Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud conf keynote - Orchestrating Least Privilege


Published on

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.

Published in: Internet
  • Be the first to comment

Cloud conf keynote - Orchestrating Least Privilege

  1. 1. Orchestrating Least Privilege
  2. 2. ~2000 Today
  3. 3. What is an Orchestrator?
  4. 4. What is an Orchestra?
  5. 5. SWARM
  6. 6. Job of a Conductor - Casting - Assign sheet music - Unify performers - Set the tempo
  7. 7. Job of an Orchestrator - Node management - Task assignment - Cluster state reconciliation - Resource Management
  8. 8. What is a Least Privilege Orchestrator?
  9. 9. What is Least Privilege?
  10. 10. A process must be able to access only the information and resources that are necessary for its legitimate purpose. Principle of Least Privilege
  11. 11. An Orchestrator that follows the principle of least privilege in the strictest manner possible. Least Privilege Orchestrator
  12. 12. Why Least Privilege?
  13. 13. Cluster Internet
  14. 14. Cluster Internet A
  15. 15. M M M AA A
  16. 16. M M M WW W
  17. 17. M M M WW W
  18. 18. How far away are we right now?
  19. 19. How do we achieve Least Privilege Orchestration?
  20. 20. Mitigating External Attacker web: image: web-app expose: 443 links: - redis redis: image: redis
  21. 21. 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"] }]
  22. 22. Mitigating MiTM Attacker rails-app: image: rails-app links: - mysql mysql: image: mysql MTLS
  23. 23. Mitigating Malicious Worker Push Worker Manager WorkerWorker
  24. 24. 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:
  25. 25. SWARM
  26. 26. Mutual TLS by default • First node generates a new self-signed CA.
  27. 27. Mutual TLS by default • New nodes can get a certificate issued w/ a token.
  28. 28. Mutual TLS by default • Workers and managers identified by their certificate.
  29. 29. Mutual TLS by default • Communications secured with Mutual TLS.
  30. 30. Secrets
  31. 31. Secrets
  32. 32. Secrets External APP
  33. 33. Thank you