fix(helm/provisioner): prefer provisioner key if both psk and key are set #15417
Conversation
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
johnstcn
commented
Nov 6, 2024
helm/provisioner/tests/testdata/provisionerd_psk_and_key.golden
Outdated
Show resolved
Hide resolved
bpmct
approved these changes
Nov 6, 2024
johnstcn
commented
Nov 7, 2024
| @@ -111,7 +111,7 @@ spec: | |||
| valueFrom: | |||
| secretKeyRef: | |||
| key: psk | |||
| name: coder-provisionerd-psk | |||
There was a problem hiding this comment.
review: renamed this to be clearer that it is not the default value
spikecurtis
reviewed
Nov 7, 2024
johnstcn
commented
Nov 7, 2024
Comment on lines
+61
to
+64
| { | ||
| name: "provisionerd_key_psk_empty_workaround", | ||
| expectedError: "", | ||
| }, |
There was a problem hiding this comment.
review: adding an explicit test for the old workaround
spikecurtis
approved these changes
Nov 7, 2024
Open
9 tasks
bpmct
pushed a commit
that referenced
this pull request
Nov 8, 2024
… set (#15417) Relates to #15416 This PR modifies the provisioner helm chart logic: - Previously, when both provisionerDaemon.keySecretName and provisionerDaemon.pskSecretName were both set, we would fail to install the chart. This required users to have an obnoxious workaround in place where setting provisionerDaemon.pskSecretName="" was required in order to use provisioner keys. We now check for pskSecretName being set to the default value when keySecretName is also specified, and switch to provisioner key authentication instead of PSK. The previous workaround is still supported. - We also had omitted to check for provisionerd.Tags being set along with provisionerDaemon.keySecretName. This would result in a crashlooping provisioner deployment, as setting both of these configuration options is not allowed. We now fast-fail the Helm deployment if we detect this scenario. (cherry picked from commit 6781b0f)
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.
Relates to #15416
This PR modifies the provisioner helm chart logic when both PSK and key are set.
Previously, we would fail to install the chart.
Now we will set
CODER_PROVISIONER_DAEMON_KEYif bothkeySecretNameandpskSecretNameare set.Otherwise we will fall back to the existing behaviour of setting
CODER_PROVISIONER_DAEMON_PSK.This removes the requirement for a previous workaround of having to set
pskSecretNameto an empty string if usingkeySecretName/keySecretKey.UPDATE: after consulting with @spikecurtis I have modified the above logic slightly.
We will now prefer
CODER_PROVISIONER_DAEMON_KEYonly ifCODER_PROVISIONER_DAEMON_PSKis unchanged from its default value. Attempting to set both explicitly will still result in a failure to install the chart.Additionally, a separate 'gotcha' exists around
provisionerDaemon.tags-- specifying bothCODER_PROVISIONER_DAEMON_KEYandCODER_PROVISIONERD_TAGSwill result in the deployment failing to start. This is now detected upfront at helm install time.