onyxia-init.sh / Vault : add optional mode for service account based auth (+ other fixes)

[phlg]

Hello,

This PR is pushing forward a new feature as well as fixing a couple of implementation flaws related to Vault management in onyxia-init.sh. Both are detailed below in distinct sections.

Feature

Feature-wise, we aim to allow for a secondary mode of authentication using the JWT generated for the service account used for the pod a service is running in. The relevant part in the changes is this :

    if [[ "$VAULT_INJECTION_SA_ENABLED" = "true" && "$VAULT_INJECTION_SA_MODE" = "jwt" ]]; then
        echo "using service account injection jwt to get vault token"
        VAULT_TOKEN=$(vault write -field="token" auth/$VAULT_INJECTION_SA_AUTH_PATH/login role=$VAULT_INJECTION_SA_AUTH_ROLE jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token)
    fi

This supposes the presence of four "new" environment variables, whose names were set arbitrarily, and can be changed if needed :

• VAULT_INJECTION_SA_ENABLED
• VAULT_INJECTION_SA_MODE
• VAULT_INJECTION_SA_AUTH_PATH
• VAULT_INJECTION_SA_AUTH_ROLE

These variables mirror the not-yet-existing region parameters suggested in this issue : InseeFrLab/onyxia-api#409. How these variables are to be set in the interactive-services is out of this scope, but the probable candidate would be to change the Helm charts to support them (values.schema.json to inject default from region into values + add a new CM or Secret to actually set the environment variables).

Also related to Vault is a minor change in the implementation : adding a new if [[ -n "$VAULT_TOKEN" ]] test prior to querying Vault - this should be transparent to existing deployments of Onyxia, but prevents errors that could happen if the SA auth method is misconfigured for instance.

The SA based auth promoted in this PR was tested with the vault-prefix tag of onyxia-api advertised in this issue : InseeFrLab/onyxia#783

Fixes

Unrelated to Vault are a couple of fixes in the code :

• The section that actually manages exporting used the echo command :

images-datascience/scripts/onyxia-init.sh

Lines 43 to 55 in 1dd4302

	if [[ $SUDO -eq 0 ]]; then
	echo "sudo alternative"
	sudo sh -c "echo $i=\"`jq -r \".data.data.$i\" <<< \"$JSON\"`\" >> /etc/environment"
	if [[ -e "${R_HOME}/etc/" ]]; then
	sudo sh -c "echo $i=\"`jq -r \".data.data.$i\" <<< \"$JSON\"`\" >> ${R_HOME}/etc/Renviron.site"
	fi
	else
	echo "not sudo alternative"
	sh -c "echo export $i=\"`jq -r \".data.data.$i\" <<< \"$JSON\"`\" >> ~/.bashrc"
	if [[ -e "${R_HOME}/etc/" ]]; then
	sh -c "echo $i=\"`jq -r \".data.data.$i\" <<< \"$JSON\"`\" >> ${R_HOME}/etc/Renviron.site"
	fi
	fi

This has the drawback of "eating" the quotes, resulting on problems for secrets whose value contain a whitespace :

(though this problem appears to be limited to the "sudo-less" mode ; secrets defined in /etc/environment appear to be parsed correctly even without quotes).

To counter this, I replaced echo with a printf command, while defining a $value variable to remove some copy/pasting.

• In that same section, there was a test specific to the presence of R :

images-datascience/scripts/onyxia-init.sh

Line 46 in 1dd4302

if [[ -e "${R_HOME}/etc/" ]]; then

In its current implementation, on any service not running R, $R_HOME is evaluated to an empty string, which in turn causes the test to check if /etc exists, which it always does. In other words, every service - with or without R - attempted to append to Renviron.site. For a R based service, it works as intended, but for the others, it in fact creates (or attempts to create) a /etc/Renviron.site file.

I replaced that test with a different one, used in a different location in onyxia-init.sh : if command -v R;