Skip to content

Comments

PWB: Support defining sensitive config values via k8s secrets#535

Closed
pat-s wants to merge 18 commits intorstudio:mainfrom
pat-s:existingSecret
Closed

PWB: Support defining sensitive config values via k8s secrets#535
pat-s wants to merge 18 commits intorstudio:mainfrom
pat-s:existingSecret

Conversation

@pat-s
Copy link
Contributor

@pat-s pat-s commented Jul 19, 2024

Applies to

  • launcherPem
  • secureCookieKey
  • userPassword
  • database.conf

When doing so, the rstudio-secret is skipped and individual mounts containing the above-mentioned secret values are injected.

This PR is breaking as the items listed are now maps and existing deployments would need to migrate from launcherPem: <value> to launcherPem.value: <value>.

I've tested this in a deployment of mine and it works as expected so far.

secureCookieKey:
  existingSecret: secure-cookie-key
launcherPem:
  existingSecret: launcher-pem
config:
  database:
    conf:
      existingSecret: database-conf
userPassword:
  existingSecret: workbench-user-password

The advantage of this approach is that it gives power to the users and makes use of "simple" k8s secrets instead of relying on some chart magic which puts together a bundled secret from plain config values.

related #520 #493

@pat-s pat-s requested review from a team, GCRev and zachhannum as code owners November 7, 2024 18:49
Co-authored-by: Graham Held <graham.held@gmail.com>
@damienleger-cure51
Copy link

Hello, I would love to see this merged! 🙏

On my setup, helm chart is deployed through ArgoCD and it doesn't support helm lookup function. This lookup function is the one responsible for checking that launcher.pem+secureCookieKey exists, resulting of those secret values regenerated on every ArgoCD sync. Having those to be set only directly on values.yaml currently to fix this situation is a problem for sensitive value.

@jforest jforest removed the request for review from colearendt February 24, 2025 17:49
name: rstudio-workbench
description: Official Helm chart for Posit Workbench
version: 0.8.7
version: 1.0.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jforest We will probably want this to be a new minor version

Suggested change
version: 1.0.0
version: 0.9.0

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pat-s can you update this to 0.10.0 please?

@jforest
Copy link
Contributor

jforest commented Feb 25, 2025

hi @pat-s can you please merge a recent main into this? There have been a lot of changes since july, including the addition of helm unittests to run!

@samcofer
Copy link
Contributor

samcofer commented Oct 2, 2025

@jforest Can you take another look at this PR?

Copy link
Contributor

@jforest jforest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pat-s You also need to update NEWS.md

We need to draw attention to the breaking changes. Things like global.secureCookieKey is no longer a string, and that string has moved to global.secureCookieKey.value

name: rstudio-workbench
description: Official Helm chart for Posit Workbench
version: 0.8.7
version: 1.0.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pat-s can you update this to 0.10.0 please?

{{- $launcherPem | nindent 6 }}
{{- end }}
{{- end }}
{{- if .Values.launcherPem.value }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes more sense to remove the {{- end }} line above and make this into an {{- else if ... we don't want to end up with 2 launcher.pem items

key: password
name: {{ .Values.userPassword.existingSecret }}
{{- end }}
{{- if .Values.userPassword.value }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should also remove the {{- end }} line above here, and make this line {{- else if ... so we don't end up duplicating the env var if both are defined

- name: rstudio-session-secret
mountPath: {{ .Values.session.defaultSecretMountPath }}
{{- end }}
{{- if or (not .Values.launcherPem.existingSecret) (not .Values.secureCookieKey.existingSecret) }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should probably match line 335

| chronicleAgent.workbenchApiKey.valueFrom | object | `{}` | Workbench API key as a `valueFrom` reference (ex. a Kubernetes Secret reference) to set as the `CHRONICLE_WORKBENCH_APIKEY` environment variable (recommended) |
| command | list | `[]` | command is the pod container's run command. By default, it uses the container's default. However, the chart expects a container using `supervisord` for startup |
| config.database.conf.value | string | 0644 | Database connection config |
| config.database.conf.existingSecret | string | `""` | Secret for database connection config |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should call out here that this is an either/or situation. That both will not be used, and that if both are defined we will ONLY use the existingSecret.

| fullnameOverride | string | `""` | the full name of the release (can be overridden) |
| global.secureCookieKey | string | `""` | |
| global.secureCookieKey.value | string | `""` | |
| global.secureCookieKey.existingSecret | string | `""` | Secret containing secureCookieKey |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should call out here that this is an either/or situation. That both will not be used, and that if both are defined we will ONLY use the existingSecret.

| launcherPem | string | `""` | An inline launcher.pem key. If not provided, one will be auto-generated. See README for more details. |
| launcher.useTemplates | bool | `false` | whether to render and use templates in the job launching process |
| launcherPem.value | string | `""` | An inline launcher.pem key. If not provided, one will be auto-generated. See README for more details. |
| launcherPem.existingSecret | string | `""` | Existing secret containing launcherPem contents |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should call out here that this is an either/or situation. That both will not be used, and that if both are defined we will ONLY use the existingSecret.

| sealedSecret.enabled | bool | `false` | use SealedSecret instead of Secret to deploy secrets |
| secureCookieKey | string | `""` | |
| secureCookieKey.value | string | `""` | |
| secureCookieKey.existingSecret | string | `""` | Secret containing secureCookieKey |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should call out here that this is an either/or situation. That both will not be used, and that if both are defined we will ONLY use the existingSecret.

@kaypeter87
Copy link

@jforest since the original author of this PR is inactive, I have created a new PR with the suggestions here: #723

@pat-s
Copy link
Contributor Author

pat-s commented Oct 9, 2025

@kaypeter87 Not sure I understand, my latest commit here was 8 days ago 👀

@kaypeter87
Copy link

@kaypeter87 Not sure I understand, my latest commit here was 8 days ago 👀

Apologies 😬 Misread the activity on the PR and didn't notice your commits last week.

This PR has been open over a year and I would love to see this merged so I created the PR. @jforest Let me know how I should proceed with my PR.

@pat-s
Copy link
Contributor Author

pat-s commented Oct 10, 2025

@pat-s can you update this to 0.10.0 please?

Did so but it doesn't make sense from a semver-perspective. This change is clearly breaking and I don't know why it shouldn't result in a major version bump.

@fh-albert-lee
Copy link
Contributor

Did so but it doesn't make sense from a semver-perspective. This change is clearly breaking and I don't know why it shouldn't result in a major version bump.

This project is still pre-1.0.0 so technically considered under "initial development". See https://semver.org/#spec-item-4:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Many projects in pre-1.0.0 follow this pattern (example, external-dns where the 0.19.0 release includes breaking changes).

@pat-s
Copy link
Contributor Author

pat-s commented Oct 15, 2025

This project is still pre-1.0.0 so technically considered under "initial development". See semver.org#spec-item-4:

To me this general argumentation doesn't make sense as it just undermines all ideas of semver when doing so over many years - especially when a project/repo is in "active" use for many years already. Even more if its an enterprise product that should not be in "initial development" ever arguably. But I am not a maintainer, just a person sharing his thoughts.

(not meant offensive against you @fh-albert-lee, just took your comment as informative)


Anyhow, hope we can get this merged soon. Maintainers: feel free to adjust versions and changelog/README entries to your liking, this doesn't need to come from my side and there's no value in me solving Chart.yaml conflicts repeatedly.

@jforest
Copy link
Contributor

jforest commented Oct 27, 2025

In order for all the tests to run properly, we'll need to move this code into a different PR, one created in the repo. #726 is that PR. I'll close this one out to remove confusion

@jforest jforest closed this Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants