Honor sshproxy enforcement in container-based backends - #4244
Merged
Conversation
VM-based backends receive the container's authorized keys uniformly, via dstack-shim task submission, which already omits the user key when DSTACK_SERVER_SSHPROXY_ENFORCED confines users to the SSH proxy. Container-based backends built the list ad-hoc inside run_job() and run_jobs() from run_spec.ssh_key_pub, so the user key reached the container regardless of the setting. Add an extra_authorized_keys argument to Compute.run_job() and run_jobs(). The caller builds it once with get_extra_authorized_keys(), which applies the setting; Kubernetes, Runpod, Slurm and Vast.ai combine it with the project key through the new build_authorized_keys(), which requires the project key to be valid and skips extra keys that cannot be parsed. The argument is deliberately unvalidated at the call site, as most backends are shim-based and ignore it. The shim path now derives its key list from the same helper so that the two cannot drift.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
VM-based backends receive the container's authorized keys uniformly, via dstack-shim task submission, which already omits the user key when DSTACK_SERVER_SSHPROXY_ENFORCED confines users to the SSH proxy. Container-based backends built the list ad-hoc inside run_job() and run_jobs() from run_spec.ssh_key_pub, so the user key reached the container regardless of the setting.
Add an extra_authorized_keys argument to Compute.run_job() and run_jobs(). The caller builds it once with get_extra_authorized_keys(), which applies the setting; Kubernetes, Runpod, Slurm and Vast.ai combine it with the project key through the new build_authorized_keys(), which requires the project key to be valid and skips extra keys that cannot be parsed. The argument is deliberately unvalidated at the call site, as most backends are shim-based and ignore it. The shim path now derives its key list from the same helper so that the two cannot drift.