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:30:06 -08:00
parent a36ca89038
commit dca3f3d86e
1 changed files with 38 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
Security-Overview.md

@ -1,19 +1,48 @@
# Overview
There are a few things to secure the SeaweedFS system:
1. Secure GRPC operations server via mutual TLS
1. Secure file upload/delete to volume server
Not covered, yet:
1. master server http access
1. filer server http access
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
Servers in SeaweedFS usually support 2 kinds of operations: gRPC and REST.
# Securing gRPC operations
The following operations are implemented via gRPC.
* requests from filer to master
* requests from master to volume servers
* delete operations from filer or other clients (mount, s3, filer.copy, filer.replicate, etc) to volume servers
* requests from clients to filer
All gRPC operations can optionally be secured via mutual TLS, by customizing the `weed scaffold -config=security` generated `security.toml` file.
# Securing Volume Servers
Since SeaweedFS is a distributed system with many volume servers, the volume servers have the risk of being changed without proper access control.
There are 2 ways to change volume servers:
1. Administrative operations via GRPC
1. Administrative operations via gRPC
1. File upload, update, and delete operations.
To control administrative operations, mutual TLS can be enabled for all GRPC calls.
To control file upload/update/delete operations, Json Web Token (JWT) is used to control access for each file id.
To control file upload/update/delete operations, Json Web Token (JWT) is used to authorize access for each file id.
## 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. copy the same `security.toml` file to the masters and all volume servers.
## 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.
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.
* All other volume server HTTP accesses are disabled when `jwt.signing` is enabled.