Auto generate API keys for a jupyter service lifetime

[pcrespov]

Running osparc python client in osparc should not require any extra effort to authorize since you are already in logged in in the platform.

When a jupyter service opens, it should include OSPARC_API_KEY and OSPARC_API_SECRET as environment variables such that the osparc client is authenticated out of the box.

This code would then work right away:

import os
import osparc

cfg = osparc.Configuration(
    username=os.environ["OSPARC_API_KEY"],
    password=os.environ["OSPARC_API_SECRET"],
)
print(cfg.host)

Moreover, the client could include this as default configuration so there is no need to add this step in the notdbook anymore.

The API keys will be auto-generated when the jupyter starts and will remain for the lifetime of the service, i.e. a new restart will produce new API keys.

This functionality should be only for jupyter services (so far, we do not have a "formal" way to distinguish what is a jupyter service)

We might introduce it as an option in the UI to activate this feature?? Or should it be there by default?

Tasks

Preview Give feedback

1. Check with @GitHK which service offers these osparc variables
2. Create demo and notify users

[pcrespov]

@newton1985 what do you think about this? would you like to add a suggestion?

[pcrespov]

@mguidon I wrote down the idea you proposed last evening. Am I missing something? Do you have other suggestions?

[newton1985]

@pcrespov - this seems like a very natural and convenient feature. But I do have two questions - 1) I recall that a user can generate multiple key pairs for a given deployment, so in the case that there is more than one pair, how do we distinguish? Also, 2) a user may be logged into one platform, but would like to launch jobs to a different platform via the API. Is there a way to retain this functionality as well?

[pcrespov]

@pcrespov - this seems like a very natural and convenient feature. But I do have two questions - 1) I recall that a user can generate multiple key pairs for a given deployment, so in the case that there is more than one pair, how do we distinguish? Also, 2) a user may be logged into one platform, but would like to launch jobs to a different platform via the API. Is there a way to retain this functionality as well?

@newton1985 very good points! thx!

1. I wonder why would you create different key pairs for a given deployment? in principle you just need one. What is the scenario you use this?
2. This is a very valid point that cannot be covered with this feature. I suggest the following: we could allow the user to define some secret variables in the Preferences tab. These variables are treated as secrets i.e. they will be encrypted in the database. When a dynamic service starts, they will be exposed in the env-vars so you can use that in your scripts. For instance, to authenticate a git repository, or api-keys to different platforms. Moreover, this approach would allow you to point to other deployments to osparc as well (e.g. from production to staging etc)

[newton1985]

@pcrespov -

1. I agree, in the majority of use-cases there will be just one API key pair. However, the UI allows the creation of more than one pair, so it would be odd if there were a mismatch between creating API keys in the UI and their use in practice in a notebook. Perhaps we could limit each user to just one pair in the UI? That said, I can think of vague scenarios where multiple pairs might be desirable, e.g. for testing/debugging or security reasons.

2. That sounds like a great idea!! If we go with this solution, let's make sure to document how to access and use the secret variables in the Preferences tab.

[pcrespov]

This has been implemented.