Using Kubernetes in Hostile Networks

June 6, 2017
We (Dark3, Inc. DBA Dark Cubed - https://darkcubed.com) pride ourselves in being a different type of cyber security company that is cheaper, easier to deploy, and faster to innovate. One of the ways we've been able to do this is by deploying our network security appliances as Kubernetes nodes. However, this came with a new security risk: operating our appliances as Kubernetes nodes in environments wherein we do not maintain full physical control of the appliances once they are deployed exposes our Kubernetes cluster authentication token to anyone with physical access to our appliances (via single-user mode,coreos.autologin mode, etc). Thus, we needed a way to limit the impact of a bad actor gaining access to an authentication token present on an appliance. Our approach to this is to sandbox each Dark Cubed customer in their own namespace and limit the scope of a customer's appliance token (the "default" service account token for their namespace) to the bare minimum necessary to access resources and run pods in that namespace using Kubernetes rule-based access control (RBAC). This talk will highlight the advantages we've seen in running our appliances as Kubernetes nodes on Container Linux, describe the bare minimum access requirements we identified for sandboxing customers in namespaces, how we went about identifying them, and the resulting RBAC resourcess and procedures we developed for securely deploying Dark Cubed customer appliances. CoreOS Fest 2017 Bryan Richardson
Previous Video
State of State in Containers
State of State in Containers

Application container technologies like Docker and Kubernetes have revolutionized the way in which develope...

Next Video
Using the Config Transpiler
Using the Config Transpiler

CoreOS Fest 2017 Derek Gonyeo