# Secret Design Docs: Multi-Tenant Orchestrator

DevFeed: [Secret Design Docs: Multi-Tenant Orchestrator](<https://devfeed.tech/articles/secret-design-docs-multi-tenant-orchestrator-35194.md>)

Original publisher: [Read original article](<https://blog.jessfraz.com/post/secret-design-docs-multi-tenant-orchestrator/>)

Published: 2019-02-12T15:09:26Z

Content type: article

Language: en

Sources: [Jessie Frazelle](<https://devfeed.tech/sources/jessie-frazelle.md>)

Topics: [Containers](<https://devfeed.tech/topics/containers.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Security](<https://devfeed.tech/topics/security.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Operating system](<https://devfeed.tech/topics/operating-system.md>), [Network](<https://devfeed.tech/topics/network.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [cgroups](<https://devfeed.tech/tags/cgroups.md>), [containers](<https://devfeed.tech/tags/containers.md>), [control-plane](<https://devfeed.tech/tags/control-plane.md>), [docker](<https://devfeed.tech/tags/docker.md>), [firewall](<https://devfeed.tech/tags/firewall.md>), [operating-systems](<https://devfeed.tech/tags/operating-systems.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

A design document for a multi-tenant container orchestrator intended to run third-party code with strong isolation. It proposes layered security controls, resource limits, network isolation, a secure minimal host operating system, and mechanisms to terminate abusive workloads and update the agent.

## Source excerpt

I thought it would be fun to start a blog post series containing design docs from my personal archive that never saw the light of day. This will be the first of the series. It contains what I thought about in detail for a general multi-tenant secured container orchestrator. The use case would be for running third party code securely isolated from each other. If you would like to see this in google doc form it also lives here. Requirements Base API to run docker images in such a way that each process is isolated entirely from all the others. Abusive actions can be terminated immediately. The agent should be auto-updateable to handle security issues as they arise. Ability to use the entire syscall interface for the processes being run. This all assumes that you have some sort of software and hardware level root of trust you can use to ensure security as well. Other Features Disallow and kill any and all bitcoin miners from using the infrastructure, BPF tracers Firewall off any existing network endpoints Firewall off the container running the process from everything around it on the local links and any reachable internal IP If one layer of isolation is compromised, rely on another layer of isolation entirely. If two layers are compromised then we at least tried our best... Design The host OS and up needs to be secure. Overview We require the following per container running: Block/io cgroups so that disk does not have noisy neighbors CPU limit Memory limit Network/bandwidth limiting Isolated network from everything else on the network (BPF or iptables) Host OS The host OS should be a reduced operating system, minimal distribution (though possibly shared with the OS used inside containers). This is for reasons of security in locking down the available weaknesses in the host environment and lessening the control plane attack surface. Operating Systems Examples of these Operating Systems include: CoreOS Container Linux Container Optimized OS Intel Clear Linux LinuxKit Featur