mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2024-01-19 02:48:24 +00:00
Explain JWT for Filer
parent
3483418d46
commit
9010af94c8
|
@ -3,8 +3,11 @@
|
|||
Since SeaweedFS is a distributed system with many volume servers, the volume servers have the risk of being changed without proper access control. We want to have the freedom to place a volume server anywhere we want, with the confidence that nobody can tamper the data.
|
||||
|
||||
We will address the volume servers first. The following items are not covered, yet:
|
||||
1. master server http REST services
|
||||
1. filer server http REST services
|
||||
- master server http REST services
|
||||
|
||||
Starting with version 2.84, the Filer HTTP REST services can be secured
|
||||
with a JWT, by setting `jwt.filer_signing.key` and
|
||||
`jwt.filer_signing.read.key` in `security.toml`.
|
||||
|
||||
In summary, here are what can be achieved.
|
||||
|
||||
|
@ -14,7 +17,7 @@ master | gRPC | secured by mutual TLS
|
|||
volume | gRPC | secured by mutual TLS
|
||||
filer | gRPC | secured by mutual TLS
|
||||
master | http | "weed master -disableHttp", disable http operations, only gRPC operations are allowed.
|
||||
filer | http | "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE.
|
||||
filer | http | **Before version 2.84:** "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.<br /><br /> **Starting with version 2.84**: secured by JWT, by setting `jwt.filer_signing.key` and `jwt.filer_signing.read.key` in `security.toml`. **This now works with the [[Amazon S3 API]].**
|
||||
volume | http write | set `jwt.signing.key` in `security.toml` in master and volume servers to check token for write operations
|
||||
volume | http read | unprotected, but url is not guessable
|
||||
|
||||
|
@ -67,4 +70,19 @@ JWT Summary:
|
|||
The volume server can also check JWT for reads. This mode does not work with `weed filer`. But this could be useful if the volume server is exposed to public and you do not want anyone to access it with a URL, e.g., paid content.
|
||||
|
||||
* To enable it, set the `jwt.signing.read.key` in `security.toml` file.
|
||||
* To obtain a JWT for read, the JWT can be read from the response header `Authorization` of `http://<master>:<port>/dir/lookup?fileId=xxxxx&read=yes`.
|
||||
* To obtain a JWT for read, the JWT can be read from the response header `Authorization` of `http://<master>:<port>/dir/lookup?fileId=xxxxx&read=yes`.
|
||||
|
||||
# Securing Filer HTTP with JWT
|
||||
|
||||
To enable JWT-based access control for the Filer,
|
||||
|
||||
1. generate `security.toml` file by `weed scaffold -config=security`
|
||||
2. set `jwt.filer_signing.key` to a secret string - and optionally `jwt.filer_signing.read.key` as well to a secret string
|
||||
3. copy the same `security.toml` file to the filers and all S3 proxies.
|
||||
|
||||
If `jwt.filer_signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `jwt.filer_signing.key`.
|
||||
|
||||
If `jwt.filer_signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `jwt.filer_signing.read.key`.
|
||||
|
||||
The S3 API Gateway reads the above JWT keys and sends authenticated
|
||||
HTTP requests to the filer.
|
||||
|
|
Loading…
Reference in a new issue