mirror of
https://github.com/chrislusf/seaweedfs
synced 2024-06-16 07:32:12 +02:00
1a194a578c
Among the changes, this replaces a couple instances of "Seaweed File System" with "SeaweedFS", for the same reason that nobody says "Mongo Data Base".
52 lines
1.9 KiB
Plaintext
52 lines
1.9 KiB
Plaintext
Design for SeaweedFS 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
|
|
|