From 9282522bb45fe43c2a690ff313fff2e49d3f1ea1 Mon Sep 17 00:00:00 2001 From: Chris Lu Date: Fri, 24 Dec 2021 22:58:20 -0800 Subject: [PATCH 1/3] Updated FUSE Mount (markdown) --- FUSE-Mount.md | 52 +++++++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/FUSE-Mount.md b/FUSE-Mount.md index 879adb7..13a34ac 100644 --- a/FUSE-Mount.md +++ b/FUSE-Mount.md @@ -170,28 +170,28 @@ Threads started! File operations: - reads/s: 1133.17 - writes/s: 755.46 - fsyncs/s: 2418.95 + reads/s: 958.24 + writes/s: 638.84 + fsyncs/s: 2045.67 Throughput: - read, MiB/s: 1133.17 - written, MiB/s: 755.46 + read, MiB/s: 958.24 + written, MiB/s: 638.84 General statistics: - total time: 60.0049s - total number of events: 258353 + total time: 60.0045s + total number of events: 218458 Latency (ms): min: 0.02 - avg: 0.23 - max: 192.95 - 95th percentile: 0.92 - sum: 59746.68 + avg: 0.27 + max: 166.61 + 95th percentile: 1.01 + sum: 59775.56 Threads fairness: - events (avg/stddev): 258353.0000/0.00 - execution time (avg/stddev): 59.7467/0.00 + events (avg/stddev): 218458.0000/0.00 + execution time (avg/stddev): 59.7756/0.00 ``` The above is single-threaded. The following uses 16 threads. @@ -223,28 +223,28 @@ Threads started! File operations: - reads/s: 2219.10 - writes/s: 1479.62 - fsyncs/s: 4766.67 + reads/s: 2152.89 + writes/s: 1435.49 + fsyncs/s: 4625.57 Throughput: - read, MiB/s: 2219.10 - written, MiB/s: 1479.62 + read, MiB/s: 2152.89 + written, MiB/s: 1435.49 General statistics: - total time: 60.0423s - total number of events: 506245 + total time: 60.0198s + total number of events: 490963 Latency (ms): min: 0.03 - avg: 1.89 - max: 272.82 - 95th percentile: 7.98 - sum: 958926.66 + avg: 1.95 + max: 215.50 + 95th percentile: 9.22 + sum: 958761.77 Threads fairness: - events (avg/stddev): 31640.3125/259.62 - execution time (avg/stddev): 59.9329/0.01 + events (avg/stddev): 30685.1875/161.07 + execution time (avg/stddev): 59.9226/0.00 ``` From d7c8569288c5cd6b4ca7d60868b4eb764a8b05ef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Kurf=C3=BCrst?= Date: Sat, 25 Dec 2021 10:04:19 +0100 Subject: [PATCH 2/3] TASK: add ui.access config docs --- Security-Configuration.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Security-Configuration.md b/Security-Configuration.md index 7fc1add..0550626 100644 --- a/Security-Configuration.md +++ b/Security-Configuration.md @@ -17,6 +17,13 @@ $ weed scaffold -config=security key = "" expires_after_seconds = 10 # seconds +# by default, if the signing key above is set, the Volume UI over HTTP is disabled. +# by setting ui.access to true, you can re-enable the Volume UI. Despite +# some information leakage (as the UI is unauthenticted), this should not +# pose a security risk. +[access] +ui = false + # jwt for read is only supported with master+volume setup. Filer does not support this mode. [jwt.signing.read] key = "" From 28f7038b31e0dd1d0626ca7a8dca0af8e348922a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Kurf=C3=BCrst?= Date: Sat, 25 Dec 2021 10:07:13 +0100 Subject: [PATCH 3/3] TASK: add docs for access.ui --- Security-Overview.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Security-Overview.md b/Security-Overview.md index f7c8565..b0d20e5 100644 --- a/Security-Overview.md +++ b/Security-Overview.md @@ -41,9 +41,15 @@ Besides gRPC mentioned above, volume servers can only be changed by file upload, ## JWT-based access control To enable JWT-based access control, 1. generate `security.toml` file by `weed scaffold -config=security` -1. set `jwt.signing.key` to a secrete string +1. set `jwt.signing.key` to a secret string 1. copy the same `security.toml` file to the masters and all volume servers. +> **Re-enabling Volume UI** +> +> By default, if the `jwt.signing.key` is set, the web UI on the volume servers is disabled. You can re-enable the web UI by +> setting `access.ui=true` in `security.toml`. Despite some information leakage (as the UI is unauthenticted), this should not +> pose a security risk, as the UI is purely read-only. + ## How JWT-based access control works * To upload a new file, when requesting a new fileId via `http://:/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://:/dir/lookup?fileId=xxxxx`.