Explain JWT for Filer

Sebastian Kurfürst 2022-01-03 13:45:51 +01:00
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.