Currently, REANA offers an optional feature to access remote storage resources based on VOMS proxy authentication. This requires to upload a lot of information as user secrets:
Whilst this is acceptable for controlled REANA cluster deployments, such as single-user deployments on researchers' laptops, it may be unacceptable for multi-user deployments, where uploading user keys as Kubernetes secrets could create a security vulnerability due to possible access by cluster administrators.
For the latter multi-user deployment conditions, we should rely more heavily on the VOMS proxy creation logic to be done on the client-side rather than doing everything on the cluster side. For example:
Researchers generate VOMS proxy files locally by themselves using voms-proxy-init as for other non-REANA services.
reana-client secrets-add uploads only the generated VOMS proxy file without further user certificates or pass phrases.
reana-auth-vomsproxy sidecar would read and expose the uploaded proxy file secret without having to generate anything by itself.
In this way, the users wouldn't have to share more secrets with the cluster beyond the VO name and the VO proxy file, since the VO proxy initialisation business would be carried out on the client-side rather than on the cluster-side. This would address the security concerns at the price of having to manually regenerate the VO proxy files for each new workflow run after the validity window expires.
Currently, REANA offers an optional feature to access remote storage resources based on VOMS proxy authentication. This requires to upload a lot of information as user secrets:
Whilst this is acceptable for controlled REANA cluster deployments, such as single-user deployments on researchers' laptops, it may be unacceptable for multi-user deployments, where uploading user keys as Kubernetes secrets could create a security vulnerability due to possible access by cluster administrators.
For the latter multi-user deployment conditions, we should rely more heavily on the VOMS proxy creation logic to be done on the client-side rather than doing everything on the cluster side. For example:
voms-proxy-initas for other non-REANA services.reana-client secrets-adduploads only the generated VOMS proxy file without further user certificates or pass phrases.reana-auth-vomsproxysidecar would read and expose the uploaded proxy file secret without having to generate anything by itself.In this way, the users wouldn't have to share more secrets with the cluster beyond the VO name and the VO proxy file, since the VO proxy initialisation business would be carried out on the client-side rather than on the cluster-side. This would address the security concerns at the price of having to manually regenerate the VO proxy files for each new workflow run after the validity window expires.