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:
- master server http REST services
- filer server http REST services
In summary, here are what can be achieved.
|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.|
|volume||http read||unprotected, but url is not guessable|
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
security.toml file. See Security Configuration.
Securing Volume Servers
Besides gRPC mentioned above, volume servers can only be changed by file upload, update, and 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,
weed scaffold -config=security
jwt.signing.keyto a secrete string
- copy the same
security.tomlfile 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.keyto 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
- When sending upload/update/delete HTTP operations to a volume server, the reqeust header
Authorizationshould be the JWT string. The operation is authorized after the volume server validates the JWT with
- JWT is set in
- JWT is read from request header
- 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, and only if the fileId is known. There are no way to iterate all files.
- All other volume server HTTP accesses are disabled when