Do not accept requests signed by untrusted keys #926

New issue

Open

opened 2024-01-24 14:33:49 +00:00 by alexvanin · 4 comments

alexvanin commented

2024-01-24 14:33:49 +00:00

Owner

With FrostFS ID contract rework, it is possible to keep there a list of storage users with associated keys and claims. In private networks, it can be used to organize access control for data-path users, managed by some soft of IAM. In public networks, contract can be controlled by Inner Ring by accepting users after GAS deposit.

In these cases, one can't access storage by creating random wallet with neo-go wallet init command. There is also a case when access is revoked by IAM or Inner Ring: delete or temporary deactivate user.

Describe the solution you'd like

Storage may check FrostFS ID contract during request validation and deny all request signed by non-existing subject.

Describe alternatives you've considered

Keep revocation list in the contract: it works for access restriction but does not solve issue with access providing.

Additional context

This approach is implemented in S3 Gateway, request middleware checks whether access token object is created by valid key from FrostFS ID contract: link.

/cc @realloc

## Is your feature request related to a problem? Please describe. With FrostFS ID contract rework, it is possible to keep there a list of storage users with associated keys and claims. In private networks, it can be used to organize access control for data-path users, managed by some soft of IAM. In public networks, contract can be controlled by Inner Ring by accepting users after GAS deposit. In these cases, one can't access storage by creating random wallet with `neo-go wallet init` command. There is also a case when access is revoked by IAM or Inner Ring: delete or temporary deactivate user. ## Describe the solution you'd like Storage may check FrostFS ID contract during request validation and deny all request signed by non-existing subject. ## Describe alternatives you've considered Keep revocation list in the contract: it works for access restriction but does not solve issue with access providing. ## Additional context This approach is implemented in S3 Gateway, request middleware checks whether access token object is created by valid key from FrostFS ID contract: [link](https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/src/commit/eae49908da137766151b25ca97995122dd2f8548/api/middleware/auth.go#L78). /cc @realloc

👍 1

alexvanin added the

frostfs-node

triage

labels 2024-01-24 14:33:49 +00:00

fyrchik was assigned by alexvanin

2024-01-24 14:33:49 +00:00

fyrchik added this to the v0.39.0 milestone 2024-01-24 17:01:14 +00:00

fyrchik commented

2024-01-24 17:03:09 +00:00

Owner

I understand why we might want to restrict e.g. Container.Create operations.
But what about sharing an object with the world? Do all readers need to belong to the frostfsid?

I understand why we might want to restrict e.g. `Container.Create` operations. But what about sharing an object with the world? Do all readers need to belong to the frostfsid?

alexvanin commented

2024-01-25 12:39:19 +00:00

Author

Owner

But what about sharing an object with the world? Do all readers need to belong to the frostfsid?

That's an interesting question. In my opinion, all object operations should be managed by policies / ACLs. But I admit this may not be suitable for all environments, including strictly private storage networks. Let's investigate what cases are valid for FrostFS.

> But what about sharing an object with the world? Do all readers need to belong to the frostfsid? That's an interesting question. In my opinion, all _object_ operations should be managed by policies / ACLs. But I admit this may not be suitable for all environments, including strictly private storage networks. Let's investigate what cases are valid for FrostFS.

fyrchik commented

2024-01-25 12:52:12 +00:00

Owner

You can allow reading object to everyone with policies/ACL
However, this breaks if we introduce additional check for the request signer, in effect we restrict "the world" to the "people registered in the frostfsid".

You can allow reading object to everyone with policies/ACL However, this breaks if we introduce additional check for the request signer, in effect we restrict "the world" to the "people registered in the frostfsid".

realloc commented

2024-01-26 07:10:03 +00:00

Owner

Using a rules engine to control access seems like a beneficial approach to me. In a public network, this tool can effectively regulate access to non-public or restricted namespaces, for example.

fyrchik modified the milestone from v0.39.0 to vNext

2024-05-14 14:09:37 +00:00