gitlab-com-seaweedfs/seaweedfs
1
0
Fork 0
mirror of https://github.com/seaweedfs/seaweedfs.git synced 2024-01-19 02:48:24 +00:00
Code Issues Projects Releases Wiki Activity

Updated Security Overview (markdown)

Chris Lu 2019-02-19 20:55:58 -08:00
parent fd2ee712ef
commit 0338347b57
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
Security-Overview.md

@ -94,12 +94,12 @@ To enable JWT-based access control,
## How JWT-based access control works
* To upload a new file, when requesting a new fileId via `http://<master>:<port>/dir/assign`, the master will use the `jwt.signing.key` to generate and sign a JWT, and set it to response header `Authorization`. The JWT is valid for 10 seconds.
* To update or delete a file by fileId, the JWT can be read from the response header `Authorization` of `http://<master>:<port>/dir/lookup?fileId=xxxxx`.
* When sending upload/update/delete HTTP operations the volume server, the same header `Authorization` should be set to the request header. If the volume server checks the JWT is valid via the `jwt.signing.key`, the operation can be executed as usual.
* When sending upload/update/delete HTTP operations to a volume server, the reqeust header `Authorization` should be the JWT string. The operation is authorized after the volume server validates the JWT with `jwt.signing.key`.
JWT Summary:
* JWT is set in `/dir/assign` or `/dir/lookup` response header `Authorization`
* JWT is read from request header `Authorization`
* JWT is valid for 10 seconds.
* JWT only has permission to create/modify/delete one fileId.
* The volume server HTTP access is only for read if the fileId is known.
* The volume server HTTP access is only for read, and only if the fileId is known. There are no way to iterate all files.
* All other volume server HTTP accesses are disabled when `jwt.signing` is enabled.