I’m having a minor panic attack looking at a new change in Tardigrade. The API keys are no longer what is granted and only access grants.
Which now for one need passphrases, and two, are no longer stand alone API keys.
These are granted from what? An API key linked to my account? Our users should have stand-alone top level access that is irrevocable by no one other than themselves. We don’t want to be the master control for our user’s data.
My biggest question here is: Is the access grant a top level grant? Or is there something above it?
Hi @AkaashMukherjee to quote the Hitchhikers Guide to the Galaxy: Don’t Panic!
Are you seeing this in the UI of the CLI?
It is true that we have had some changes , and that some of those relate to naming conventions. IBut first I want to check and be sure that we’re talking about the same thing.
If you select “Continue in the CLI”, you will get a “token”, which is compatible with API key and serving the same purpose, but you also have an ability to limit this kind of access grant for example to only one bucket with write-only rights on highest level. All derived access grants will have these permissions by default and you will have an ability to strict it even more, include time-dependent validity.
If you select “Continue in the Browser”, you can generate an access grant with all needed permissions and encryption phrase and get the same access grant as if you call uplink share command, but now you do not need an uplink CLI to do so.
Ok, I was using the continue with cli option on tardigrade. To be clear our use case is patient data. Each patient should have the master access to their data. There should be no way for us or anyone else to access their data buckets or modify their access to their data. The patient should always have the highest level access, even higher than us. I understood that with API keys this was how it worked, one key per patient and each patient has the highest level access. I just want to be clear that the tokens work this way for our use case. Although its possible that I misunderstood how the API keys worked in the first place.
wow I can see how that would be highly important to you – all data has privacy considerations. but patient data is especially sensitive. Does Alexeys input help or do you need further clarification? Im happy to ping an engineer on your behalf.
Yes, they working exactly like this. We just extended the possibility to limit access earlier, on API key level.
If you use the default settings it will be the same as an usual unrestricted API key.
In other words - all old API keys were unlimited by default.
However, you, as a project owner, can have an access to the buckets by creating another API key without restrictions (i.e. with full unlimited access).
If you use only API keys for your patients, then you must strict each API key to only their buckets, and now it’s possible.
Otherwise, anyone with an unlimited API key from your project will have full access to the buckets, but not the content (if they use different encryption phrases).
This is one of the reasons why we have added this functionality.
The API keys was intended to give full access to the project, permissions expected to be added later, when you generate a shared access grant via uplink share, and applications should use this access grant to have a granular access to only allowed objects and buckets.
But we figured out that there are such cases as you described - i.e. the user do not want to generate an access grant and uses only API keys, in such a case only application would decide regarding access limits.
I looked over our code and it seems that this was indeed what had been done. The patient client uses an API key and random passphrase to create a serialized access. After this, without knowing that (client-created) passphrase or having the resulting access grant, there’s no way for anyone, the project owner included, to have access to created keys within the buckets. I tested it out and it still seems to work this way with the tokens. Unless I’m missing something.
Sorry to require all this clarification, it’s that from a regulatory standpoint our product can’t exist without being sure about this.
You don’t need to sorry, we are here to help.
You can see keys only in encrypted form unless you have exactly the same password phrase or access grant for that bucket.
