Store both public and private client keys in secret scopes#3775
Merged
Store both public and private client keys in secret scopes#3775
Conversation
Collaborator
7 failing tests:
|
9cc7630 to
da13a01
Compare
dcbfd5b to
d95fc1d
Compare
d307bfa to
a988e53
Compare
anton-107
approved these changes
Oct 30, 2025
| "github.com/databricks/databricks-sdk-go" | ||
| ) | ||
|
|
||
| type AuthorizedKeysManager struct { |
Contributor
There was a problem hiding this comment.
Consider adding a comment documenting the lifecycle of the keys and when they are added
But this time also store private client key in the secrets scope.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 14, 2025
## Changes Based on #3775 Make a simple connection with "echo 'Hello'" and check that databricks ssh connect output has it. SSH tunnel requires linux releases to be present, so it can upload them to the workspace for the ssh server to use. Added the build step directly to the acceptance_test, similar to how we build the CLI itself there. Initially I've modified our runner to install goreleaser and running make snapshot-release, but it takes over 10m on linux machines. Current build step only adds ~1m to the test time.
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
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.
Changes
Before we were passing a client key name (a secret name that contains the actual client public key) to the ssh server job. After it's started, the ssh server was only accepting one client with one specific key. This is a problem when you try to ssh to the same cluster under the same databricks user from multiple different client machines (that have different ssh keys).
Our integration tests can't work consistently because of this, and we've already got one customer report about this problem.
The main change here is that now we don't always generate key-pairs on the client, but check if the pair already exists in the secret scope and use it. And if not, we generate the pair and save both keys to the scope (and before we were only saving public key there)