mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2024-11-30 15:19:01 +08:00
52 lines
1.9 KiB
Plaintext
52 lines
1.9 KiB
Plaintext
Design for Seaweed-FS security
|
|
|
|
Design Objectives
|
|
Security can mean many different things. The original vision is that: if you have one machine lying around
|
|
somewhere with some disk space, it should be able to join your file system to contribute some disk space and
|
|
network bandwidth, securely!
|
|
|
|
To achieve this purpose, the security should be able to:
|
|
1. Secure the inter-server communication. Only real cluster servers can join and communicate.
|
|
2. allow clients to securely write to volume servers
|
|
|
|
Non Objective
|
|
Multi-tenant support. Avoid filers or clients cross-updating files.
|
|
User specific access control.
|
|
|
|
Design Architect
|
|
master, and volume servers all talk securely via 2-way SSL for admin operations.
|
|
upon joining, master gives its secret key to volume servers.
|
|
filer or clients talk to master to get secret key, and use the key to generate JWT to write on volume server.
|
|
A side benefit:
|
|
a time limited read feature?
|
|
4. volume server needs to expose https ports
|
|
|
|
HTTP Connections
|
|
clear http
|
|
filer~>master, need to get a JWT from master
|
|
filer~>volume
|
|
2-way https
|
|
master~ssl~>volume
|
|
volume~ssl~>master
|
|
|
|
file uploading:
|
|
when volume server starts, it asks master for the secret key to decode JWT
|
|
when filer/clients wants to upload, master generate a JWT
|
|
filer~>volume(public port)
|
|
master~>volume(public port)
|
|
|
|
Currently, volume server has 2 ip addresses: ip and publicUrl.
|
|
The ip is for admin purpose, and master talk to volume server this way.
|
|
The publicUrl is for clients to access the server, via http GET/POST/DELETE etc.
|
|
The write operations are secured by JWT.
|
|
clients talk to master also via https? possible. Decide on this later.
|
|
|
|
Dev plan:
|
|
1. volume server separate admin from public GET/POST/DELETE handlers
|
|
The step 1 may be good enough for most use cases.
|
|
|
|
If 2-way ssl are still needed
|
|
2. volume server add ssl support
|
|
3. https connections to operate on volume servers
|
|
|