Repository navigation
fix(docker): register custom server public key in docker_ksm_utility - #2448
Merged
Merged
Conversation
maksimu
marked this pull request as ready for review
October 16, 2026 15:37
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.
docker_ksm_utility.py, which downloads and uploads config.json for the service-mode container, uses the KSM SDK directly and never imports keepercommander.rest_api, so the KEEPER_SERVER_PUBLIC_KEY fix from #2447 doesn't apply to it. Against SMK, every get_secrets call fails with
encrypted transmission key is invalid.This change registers the same env vars in the SDK's key table before creating the SecretsManager. It copies the logic rather than importing rest_api, so the script stays light. The swallowed UID-lookup exception is now printed, because before this the key error only appeared as a confusing title-lookup failure.
I checked locally that with the env vars set the SDK uses the SMK key for id 7. I haven't run it in a container against SMK. The container also needs the two env vars,
REQUESTS_CA_BUNDLEwith SMK's CA, and a hostname for SMK it can reach (the KSM config and file URLs currently saylocalhost).