From 9010af94c8addba22a57ca7a422a7577502533c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Kurf=C3=BCrst?= Date: Mon, 3 Jan 2022 13:45:51 +0100 Subject: [PATCH] Explain JWT for Filer --- Security-Overview.md | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/Security-Overview.md b/Security-Overview.md index b0d20e5..45d8fa6 100644 --- a/Security-Overview.md +++ b/Security-Overview.md @@ -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.

**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://:/dir/lookup?fileId=xxxxx&read=yes`. \ No newline at end of file +* To obtain a JWT for read, the JWT can be read from the response header `Authorization` of `http://:/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.