a quick design for preventing Storj Select accesses registration mismatches

[amwolff]

Currently, it's possible to create an access grant that's meant to be used only with us-select-1 edge services (for example) and register it at auth.storjshare.io instead of auth.us-select-1.storjshare.io.

A simple idea that prevents misuse of access grants targeting different auth services is to

1) make sure auth service is aware of the placement region identifies it's primarily intended for 2) add an optional placement region identifier to access grants and make the client code sign it 3) make auth reject registration requests of access grants not intended for it 4) for backwards compatibility, all access grants without the identifier can still be registered at any auth

This won't resolve complex cases such as "created access grant for placement X, then added a new bucket with placement Y and placement X became something else" but it works for the simple case of misuse described above and by lack of evidence of true misuse patterns, I'd estimate that would cover 99% cases of misuse.

Links

• https://storj.dev/dcs/api/s3/s3-compatibility#location-constraint
• https://storjlabs.atlassian.net/wiki/spaces/ENG/pages/2617278478?focusedCommentId=2956853252

[amwolff]

@pwilloughby said:

you're talking about adding a flag to the uplink register command? --location us-select-1 or --location global?

@halkyon said:

Is this for implementing the quick design or to expand the design? I wasn’t clear on the intention of the issue

that’s a good point Paul. EU and AU select also use public authservice only (so far), but I guess you’d just not restrict those

Ideally we don’t have separate authservices at all, or did that boat already sail?

@pwilloughby said:

If we make further inroads into enterprise I think the trend will only be towards more and more restrictive.