[Docs]: Tenant isolation guide#3913
Conversation
Add a guide with instructions on hardening the isolation between tenants and hosts (where "tenants" can refer to users or jobs, not necessarily organizations; couldn't come up with a more concise yet descriptive title).
| |---|---|---| | ||
| | `1` | `HOST_FOR_MULTINODE_ONLY` | Host for distributed tasks, bridge otherwise | | ||
| | `2` | `HOST_WHEN_POSSIBLE` | Host whenever the job occupies a full instance (default) | | ||
| | `3` | `FORCED_BRIDGE` | Always bridge, including distributed tasks | |
There was a problem hiding this comment.
Must be explicit that this prevents both distributed tasks and PD disaggregation to work
There was a problem hiding this comment.
Technically, distributed tasks can still work with FORCED_BRIDGE, e.g., if they use some external coordinator and don't need inter-job communication.
I've updated the section to describe the difference between host and bridge networking, and mentioned that host networking facilitates distributed tasks and routers. This should help users make a more informed decision
|
|
||
| This gives unrestricted access to the underlying instance, bypassing container boundaries. | ||
|
|
||
| If desired, host SSH access can be disabled server-wide by configuring the [SSH proxy](server-deployment.md#ssh-proxy) and setting the following environment variable when starting the `dstack` server: |
There was a problem hiding this comment.
DOn't we want to include a guide on how to set up SSH proxy here?
There was a problem hiding this comment.
There's a reference to the deployment guide, I wouldn't duplicate the guide here
| `dstack` assumes mutual trust between users of the same project. While users' jobs run in Docker containers, users and their containers may have broad access to the underlying hosts. This guide explains how to restrict access to the host when stronger boundaries are required. | ||
|
|
||
| !!! info "Disclaimer" | ||
| Even with all precautions, complete isolation on shared hardware is hardly achievable — container escape vulnerabilities are common. The best way to provide true isolation between users is to place them in different `dstack` projects and not share hardware between them. |
There was a problem hiding this comment.
Is there a way to make it sound less harsh? IMO its too much focusing around "hardly achievable" i don't think the main question of the reader is whether its archivable or not. Maybe we can make the text here more neutral? Or a the very least don't frame it as "Disclaimer".
There was a problem hiding this comment.
Updated the wording
|
|
||
| To block runs that request privileged mode, write a [REST plugin](../reference/plugins/rest/index.md) or a [Python plugin](../reference/plugins/python/index.md) with an apply policy. | ||
|
|
||
| <div editor-title="src/isolation_plugin/__init__.py"> |
There was a problem hiding this comment.
IMO plugins are still experimental and I'm somewhat not super confident of pushing everyone in this direction just yet. Maybe we could make it a collapsible section? Or even better add this example to the Plugins documentation, and only use a link from here - as we do with SSH proxy?
There was a problem hiding this comment.
The plugins documentation already has a similar example actually. I updated it and removed the inline example from this guide
|
@peterschmidt85, I'm merging, but if you feel like adjusting anything else, please do |
3 participants
Add a guide with instructions on hardening the
isolation between tenants and hosts (where
"tenants" can refer to users or jobs, not
necessarily organizations; couldn't come up with a
more concise yet descriptive title).