-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Pick secret file provide upload file feature #191
Comments
@jugdemon just to clarify: what exactly do you mean with that:
Would it be enough to have the secrets available for the session of the user? Then this would still mean that if he restarts his session, there would still be another upload of the secrets necessary occasionaly. But would that solve your issue? We don't want to store secrets in the databases of ODTP. |
Dear Sabine, Yes, that is what we need. As it stand right now, we need to pick the secret file from the file System where ODTP is installed. As we host an ODTP Server, the user has no access to the file System and cannot deposit files in the server file System. Right now an Server Administrator needs to place the file there which is in convenient. I should have been more precise - I meant that the secret file gets placed in the local odtp folder on the file System, not the ODTP database. I see the advantage of the secret being uploaded per session and not being locally stored. Either solution works, what matters is that the secret can be provided via file upload so that a person without Server access and provide the secret. I hope that makes sense. |
@jugdemon One more comment on this: I will then try to add the secrets automatically and not offer the secret upload from file in the execution runs any more. The |
@jugdemon So the same is true for uploading parameters from file for the executions. Is that correct: they should not be picked from a file on the server but rather be uploaded from the users computer. Is that correct? |
@sabinem There should definitely be an option to upload it from the users computer in our context of a server-deployed ODTP with no access rights for users. I think there can be secrets that are secret from users which are stored on the server and loaded like it is done right now. For instance if you don't want the user to access the data directly like the FSO population statistics, they shouldn't get the login credentials for that. In the best case, I think both is supported. Maybe frame it as "select server secret" and "upload own secret"? |
Description:
We are running ODTP now on a server where the user of the Dashboard cannot access the underlying machine. To provide secrets, it would be great if the user can upload the file from the dashboard and the file gets stored locally in ODTP.
Importance Level
(High)
This feature is critical to make ODTP available via a dashboard to external users.
Origin
We want to showcase ODTP to ETH internal partners and they should be able to run twins themselves via the dashboard which we make available to them. Adding secrets.
User Impact
Users without CLI access cannot add new secrets at the moment. We want to have dashboard only users. It is critical.
Mockups or Diagrams
None
Affected Components (examples: components, modules, … )
All components that need secrets but the user cannot access the CLI.
Technical Requirements (if possible, otherwise completed by SDSC)
Detailed technical specifications or requirements needed to implement the feature. This could include algorithms, data structures, APIs, or third-party services.
Related Documents/Links:
References to any related documentation, user stories, tickets, or external resources that provide additional context.
Dependencies (if possible, otherwise completed by SDSC):
Identification of any other features, systems, or processes that the proposed feature depends on or interacts with. This can be considered a “ready if” field and it will define what’s needed to have in order to start the development.
Acceptance criteria:
Specific criteria or metrics for evaluating the success or effectiveness of the feature once implemented.
The text was updated successfully, but these errors were encountered: