Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Enemy Within: Running untrusted code in Kub...

Ian Lewis
November 17, 2019

The Enemy Within: Running untrusted code in Kubernetes

Containers are a great way to deploy and isolate application resources but they can fall short when it comes to security isolation. How do you improve the security of a container while maintaining the flexible and dynamic resource usage of a container? There are many options for sandbox containers but which is right for you?

In this talk I will explore sandbox runtimes in depth with a focus on use-cases and challenges on their implementation and maintenance. I will dive into the container security model, the use cases for sandbox pods. I will discuss various approaches and their tradeoffs before diving into the architecture of gVisor, how it differs from virtual machine based sandboxes, and how we are working to make running untrusted code feel more like the containers you know and love. Finally, I will bring it all together with a demo of best practices for using gVisor to run untrusted user code in a Kubernetes cluster.

Ian Lewis

November 17, 2019
Tweet

More Decks by Ian Lewis

Other Decks in Technology

Transcript

  1. 3 gVisor • Running untrusted code • Third-party/User uploaded code

    ◦ Vendor-built apps ◦ SaaS/Serverless • Complex code/Complex user input ◦ Video/Image transcoding ◦ Machine learning • Code you wrote but you don't trust yourself…. So you want to run some code...
  2. 13 gVisor • Protects attackers from escaping the runtime environment

    • Code running in the sandbox is untrusted • Goal: Reduce the attack surface for untrusted code • Method: Reduce the amount of trusted or privileged code (e.g. kernel code) that gets run. ◦ Achieved through abstraction/virtualization of host. Container Sandboxes
  3. 15 gVisor • Pros ◦ Same performance as normal processes

    ◦ Uses built-in OS features. • Cons ◦ They aren't good security isolation boundaries ◦ Any one bug in the host kernel could lead to a full host compromise ◦ Seccomp sandboxes must be tweaked per application Containers & Seccomp sandboxes
  4. 17 gVisor • Pros ◦ Reasonably fast ◦ Low overhead/startup

    ◦ Good compatibility • Cons ◦ Can't bring your own container (must be specially crafted) ◦ Many limitations (fork, dynamic loading of libraries, etc.) Unikernels
  5. 20 gVisor • Pros ◦ Hardware acceleration. Raw-performance is good

    ◦ Maintenance is well understood • Cons ◦ Security implications often not well understood ◦ Nested virtualization slow & source of security bugs ◦ Resource management difficult ◦ Often requires layers of indirection and proxies Virtual Machines
  6. 22 gVisor • Hybrid approach = Virtualization w/ Host Resources

    • Uses the same principle of virtualization as VMs ◦ Virtualization at the OS; Linux Syscall layer • Reduces the host attack surface ◦ Calls to the host OS are controlled by the Sentry ◦ Most syscall logic handled by Sentry ◦ No syscalls are "passed through". Applications cannot pass arbitrary arguments to the host kernel. gVisor (gvisor.dev)
  7. 25 gVisor gVisor (gvisor.dev) KVM/ptrace Gofer Gofer Gofers Containers Containers

    Host Linux Kernel Containers Sentry Sandbox User Kernel 9P runsc OCI seccomp + ns seccomp + ns
  8. 26 gVisor • Container-Native ◦ Built from the ground up

    for containers ◦ Host process - resource limits, secrets, volumes, etc. • Portable ◦ Can run inside of VMs ◦ Doesn't need hardware support but can use it if available • Resource Efficient ◦ Able to use the host OS for resource management ◦ Workloads can be tightly packed gVisor (gvisor.dev)
  9. 27 gVisor • Cons ◦ Compatibility (always getting better) ◦

    I/O Performance (also being improved) gVisor (gvisor.dev)
  10. 28 gVisor apiVersion: node.k8s.io/v1beta1 kind: RuntimeClass metadata: name: myclass #

    The name of the corresponding CRI configuration handler: myhandler Runtimes & Kubernetes
  11. 30 gVisor • Be aware of defaults ◦ K8s is

    optimized for ease-of-use, not security ◦ CPU/Memory/Disk limits • Network/Disk isolation ◦ Network access: Use NetworkPolicy ◦ Arbitrary packet injection ◦ File writes/permissions: Use read-only filesystems ◦ No throttling mechanism: use cgroups What's not protected?
  12. 31 gVisor gVisor https://gvisor.dev/ Gitter: https://gitter.im/gvisor/community Mailing lists: gvisor-users, gvisor-dev

    Thanks! https://katacontainers.io/ Nabla Containers https://nabla-containers.github.io/