fix: add user secret key when using saved secrets

[olevski]

/deploy renku=feat-jupyter-free-sessions amalthea-sessions=main renku-ui=andrea/jupyter-free-build renku-gateway=master extra-values=amalthea-sessions.deployCrd=false

[olevski]

This change is part of the following stack:

• [REBASE only]: Migrate notebooks and add new amalthea #418
  • fix: git connectors and reading logs #518
    • fix: add user secret key when using saved secrets #519 ◀

_{Change managed by git-spice.}

[RenkuBot]

You can access the deployment of this PR at https://renku-ci-ds-519.dev.renku.ch

[leafty]

Note: for user secrets, we inject the data service API URL along with the user's Renku token to decrypt the secrets and not the cipher key directly. Should this approach be used for data connector secrets as well?

The init user secrets container then grabs the key from the internal API endpoint.

[m-alisafaee]

Thanks Tasko!

[olevski]

Note: for user secrets, we inject the data service API URL along with the user's Renku token to decrypt the secrets and not the cipher key directly. Should this approach be used for data connector secrets as well?

The init user secrets container then grabs the key from the internal API endpoint.

@leafty for the data connectors I followed the same thing we do right now in the renku repo. There we add the the decryption key in the secret that contains the configuration. And the csi rclone finishes the decryption of the saved secret.

We cannot use an init container because the pod cannot start at all (including the init containers) until the volumes are mounted. And the volume (i.e. data connector) cannot be mounted until rclone has the fully decrypted secret in order to do the mounting. So we cannot use an init container to decrypt the data connector secrets.

[RenkuBot]

Tearing down the temporary RenkuLab deplyoment for this PR.