RFC: RBAC Support for PD #62
Conversation
Signed-off-by: PhotonQuantum <[email protected]>
PhotonQuantum
force-pushed
the
master
branch
from
149a656 to
ba03f3e
Compare
|
|
||
| - PD stores `User`s in a KV database (etcd). | ||
| - Username: string | ||
| - Hash: string (sha256) |
There was a problem hiding this comment.
I assume this is the hash of the password? In which case sha256 is inappropriate. You should either salt the password and use multiple iterations of sha512, or use a hash algorithm specifically designed for passwords, e.g., Argon2d.
There was a problem hiding this comment.
I'm worried about the potential performance penalty if we use key derivation algorithms.
There was a problem hiding this comment.
That is a feature, not a bug - being able to hash the password quickly is a security risk. I think a token based scheme would be more performant?
| - Roles: a set of strings (role names) | ||
| - A client (TiDB/TiKV/pd-ctl/…) must provide a pair of username and password to | ||
| gain access to PD APIs (including HTTP and gRPC endpoints). | ||
| - Clients using HTTP APIs should send requests with a basic authentication header. |
There was a problem hiding this comment.
Can users always use https to contact PD? Using http for this would be insecure.
There was a problem hiding this comment.
That's a good idea! We may enforce TLS when authentication is enabled.
| - A client (TiDB/TiKV/pd-ctl/…) must provide a pair of username and password to | ||
| gain access to PD APIs (including HTTP and gRPC endpoints). | ||
| - Clients using HTTP APIs should send requests with a basic authentication header. | ||
| - Clients using gRPC should set its username and password in the meta field. |
|
|
||
| ### Authentication | ||
|
|
||
| - PD stores `User`s in a KV database (etcd). |
There was a problem hiding this comment.
Will this require an etcd access on every request? That seems like it could be a big performance hit (though I am just guessing).
There was a problem hiding this comment.
I believe an in-memory cache can mitigate the performance regression.
There was a problem hiding this comment.
could you write this optimization and the cache maintenance mechanism to the RFC?
|
|
||
| ## Future Additions | ||
|
|
||
| - Token-based authentication. |
There was a problem hiding this comment.
token-based authorization is considerably more secure than using username/password and IMO should be the only mechanism supported. There are fairly standard approaches which can be used, e.g., OAuth
There was a problem hiding this comment.
Maybe different users will have different security models? I'm thinking about providing several auth methods, including password-based, token-based, and certificate-based ones.
There was a problem hiding this comment.
From a security perspective, the more auth methods there are, the less secure your system is. Could we support a single, token-based auth method and provide token generation from username/password in the client?
|
|
||
| ## Motivation | ||
|
|
||
| PD server exposes its APIs to the network via HTTP or gRPC endpoints. |
There was a problem hiding this comment.
are there any guidelines about when to use HTTP and gRPC?
|
etcd already supports RBAC. What are the issues with just using that? |
No description provided.