[Feature Request]: Switch to kubernets_secret option in place of user_credential option on elyrasecret

[harshad16]

Feature description

Currently, we are using the cos_auth_type: 'USER_CREDENTIALS' which is allowing the creds to be uploaded as env var in the elyra export pipeline. In place of the USER_CREDENTIAL option , we would like to switch to KUBERNETES_SECRET type. so the export pipeline references kubernetes secret instead of simple env var,

Describe alternatives you've considered

switch of the export functionality, which is not recommended as it is a feature.

Anything else?

No response

[shalberd]

working on something similar on the Airflow processor side in Elyra pipeline editor, good idea to also handle it that way in dashboard and KFP. In airflow processor, the access key and secret are passed as container env from a k8s model secret, too when assembling a DAG

https://airflow.apache.org/docs/apache-airflow/1.10.2/_modules/airflow/contrib/kubernetes/secret.html

https://github.com/elyra-ai/elyra/blob/main/elyra/pipeline/airflow/processor_airflow.py#L627

By the way, security-architecture-wise, what do you think about the discussion on whether putting env vars values with sensitive information directly into the pipeline? That seems similar to the KFP USER_CREDENTIALS way we get rid of here ... great job, KFP is ahead of the curve here to Airflow.

apache/airflow#28086

The argument they have against it is:

Some of the users pass the credentials using environment variables, but this is inherently insecure, because environment variables passed to the Pod might be displayed and accessed using various mechanisms and certain scenarios (like failing to create Pod) might reveal it in various logs which are not protected by secret masker.

not only that, but Kubernetes secrets values are visible in Git if using Git as a mechanism to store jobs.

At least airflow doesn't have another way than env var plaintext value (yet) to get secrets into a pod.

[andrewballantyne]

Triaging this without the team as it is critical for the release at the end of the week. Spoke with @harshad16 about this and the solution looks good to me. Once we test it with the generated images from the PR, we can look at merging it.

[andrewballantyne]

By the way, security-architecture-wise, what do you think about the discussion on whether putting env vars coming from secret values into the pipeline?

@shalberd are you considering the solution where we don't provide the Data Connection information as env vars to the Pod?

We mount all our secrets the same way against the workbench 🤔

[shalberd]

are you considering the solution where we don't provide the Data Connection information as env vars to the Pod

In airflow and its kubernetes pod operator ... no, not really, the issue at Airflow in more related to the secret values themselves being passed to the PodSpec, not the configmap or secret name and keys.

Their pod operator does not have envFrom support yet.

We mount all our secrets the same way against the workbench

Yes, and it would be the same even with envFrom from configmap or secrets, totally ok.
I just think the Airflow folks raised a valid point there medium-term for their implementation.

Their pod operator takes the env values with secret value, e.g. a password, directly instead of from a secret or configmap ref.

The main issue is more that pipeline code in the case of Airflow dags, stored in git, has cleartext values, not optimal.

The advantage when just putting configmap or secret name plus key in the pipeline code is that there is no secret value in git or pipeline code.

so @harshad16 is doing it just right, in fact, very much so indeed.