[#118] Replace ACLs with polices in readme

Signed-off-by: Alex Vanin <a.vanin@yadro.com>
This commit is contained in:
Alexey Vanin 2024-06-24 16:54:55 +03:00
parent 3741e3b003
commit 27478995b5

View file

@ -466,13 +466,13 @@ You can always upload files to public containers (open for anyone to put
objects into), but for restricted containers you need to explicitly allow PUT objects into), but for restricted containers you need to explicitly allow PUT
operations for a request signed with your HTTP Gateway keys. operations for a request signed with your HTTP Gateway keys.
If your don't want to manage gateway's secret keys and adjust eACL rules when If you don't want to manage gateway's secret keys and adjust policies when
gateway configuration changes (new gate, key rotation, etc) or you plan to use gateway configuration changes (new gate, key rotation, etc) or you plan to use
public services, there is an option to let your application backend (or you) to public services, there is an option to let your application backend (or you) to
issue Bearer Tokens ans pass them from the client via gate down to FrostFS level issue Bearer Tokens and pass them from the client via gate down to FrostFS level
to grant access. to grant access.
FrostFS Bearer Token basically is a container owner-signed ACL data (refer to FrostFS FrostFS Bearer Token basically is a container owner-signed policy (refer to FrostFS
documentation for more details). There are two options to pass them to gateway: documentation for more details). There are two options to pass them to gateway:
* "Authorization" header with "Bearer" type and base64-encoded token in * "Authorization" header with "Bearer" type and base64-encoded token in
credentials field credentials field
@ -482,33 +482,31 @@ For example, you have a mobile application frontend with a backend part storing
data in FrostFS. When a user authorizes in the mobile app, the backend issues a FrostFS data in FrostFS. When a user authorizes in the mobile app, the backend issues a FrostFS
Bearer token and provides it to the frontend. Then, the mobile app may generate Bearer token and provides it to the frontend. Then, the mobile app may generate
some data and upload it via any available FrostFS HTTP Gateway by adding some data and upload it via any available FrostFS HTTP Gateway by adding
the corresponding header to the upload request. Accessing the ACL protected data the corresponding header to the upload request. Accessing policy protected data
works the same way. works the same way.
##### Example ##### Example
In order to generate a bearer token, you need to have wallet (which will be used to sign the token) and In order to generate a bearer token, you need to have wallet (which will be used to sign the token)
the address of the sender who will do the request to FrostFS (in our case, it's a gateway wallet address).
Suppose we have: 1. Suppose you have a container with private policy for wallet key
* **NhVtreTTCoqsMQV5Wp55fqnriiUCpEaKm3** (token owner (gateway address))
Firstly, we need to encode the container id and the sender address to base64 (now it's base58).
So use **base58** and **base64** utils.
1. Encoding token owner id:
``` ```
$ echo 'NhVtreTTCoqsMQV5Wp55fqnriiUCpEaKm3' | base58 --decode | base64 $ frostfs-cli container create -r <endpoint> --wallet <wallet> -policy <policy> --basic-acl 0 --await
# output: NezFK4ujidF+X7bB88uzREQzRQeAvdj3Gg== CID: 9dfzyvq82JnFqp5svxcREf2iy6XNuifYcJPusEDnGK9Z
$ frostfs-cli ape-manager add -r <endpoint> --wallet <wallet> \
--target-type container --target-name 9dfzyvq82JnFqp5svxcREf2iy6XNuifYcJPusEDnGK9Z \
--rule "allow Object.* RequestCondition:"\$Actor:publicKey"=03b09baabff3f6107c7e9acb8721a6fc5618d45b50247a314d82e548702cce8cd5 *" \
--chain-id <chainID>
``` ```
2. Form a Bearer token (10000 is lifetime expiration in epoch) and save it to **bearer.json**:
2. Form a Bearer token (10000 is lifetime expiration in epoch) to impersonate
HTTP Gateway request as wallet signed request and save it to **bearer.json**:
``` ```
{ {
"body": { "body": {
"allowImpersonate": true, "allowImpersonate": true,
"ownerID": {
"value": "NezFK4ujidF+X7bB88uzREQzRQeAvdj3Gg=="
},
"lifetime": { "lifetime": {
"exp": "10000", "exp": "10000",
"nbf": "0", "nbf": "0",
@ -521,7 +519,7 @@ $ echo 'NhVtreTTCoqsMQV5Wp55fqnriiUCpEaKm3' | base58 --decode | base64
3. Sign it with the wallet: 3. Sign it with the wallet:
``` ```
$ frostfs-cli util sign bearer-token --from bearer.json --to signed.json -w ./wallet.json $ frostfs-cli util sign bearer-token --from bearer.json --to signed.json -w <wallet>
``` ```
4. Encode to base64 to use in header: 4. Encode to base64 to use in header:
@ -542,47 +540,32 @@ $ curl -F 'file=@cat.jpeg;filename=cat.jpeg' -H "Authorization: Bearer Ck4KKgoEC
# } # }
``` ```
##### Note ##### Note: Bearer Token owner
For the token to work correctly, you need to create a container with a basic ACL that:
1. Allow PUT operation to others You can specify exact key who can use Bearer Token (gateway wallet address).
2. Doesn't set "final" bit To do this, encode wallet address in base64 format
For example:
``` ```
$ frostfs-cli -w ./wallet.json --basic-acl 0x0FFFCFFF -r 192.168.130.72:8080 container create --policy "REP 3" --await $ echo 'NhVtreTTCoqsMQV5Wp55fqnriiUCpEaKm3' | base58 --decode | base64
# output: NezFK4ujidF+X7bB88uzREQzRQeAvdj3Gg==
``` ```
To deny access to a container without a token, set the eACL rules: Then specify this value in Bearer Token Json
```
$ frostfs-cli -w ./wallet.json -r 192.168.130.72:8080 container set-eacl --table eacl.json --await --cid BJeErH9MWmf52VsR1mLWKkgF3pRm3FkubYxM7TZkBP4K
```
File **eacl.json**:
``` ```
{ {
"version": { "body": {
"major": 0, "ownerID": {
"minor": 0 "value": "NezFK4ujidF+X7bB88uzREQzRQeAvdj3Gg=="
}, },
"containerID": { ...
"value": "mRnZWzewzxjzIPa7Fqlfqdl3TM1KpJ0YnsXsEhafJJg="
},
"records": [
{
"operation": "PUT",
"action": "DENY",
"filters": [],
"targets": [
{
"role": "OTHERS",
"keys": []
}
]
}
]
}
``` ```
##### Note: Policy override
Instead of impersonation, you can define the set of policies that will be applied
to the request sender. This allows to restrict access to specific operation and
specific objects without giving full impersonation control to the token user.
### Metrics and Pprof ### Metrics and Pprof
If enabled, Prometheus metrics are available at `localhost:8084` endpoint If enabled, Prometheus metrics are available at `localhost:8084` endpoint