Hi Keyong,
Thanks for reviewing the proposal.
1. Should we store the shard secrets in Ratis among masters since leader
may change at any time?
That's a good point. The secret should be stored in Ratis, as you've
mentioned, because the leader can change at any time. Mridul and I
discussed this but haven't yet included it in the document. We will need to
enable TLS communication between the masters, which I believe Ratis
supports. Ratis also maintains a local log where state information is
persisted. Since we're dealing with secrets, encryption may be necessary,
although that might be beyond the current scope. Once we add support for
encryption at rest, we can then implement encrypted secret storage within
Ratis..
2. In case of worker graceful restart, should the worker store the shared
secret in leveldb before it stops,
or ask the master after it restarts? (The later seems to be necessary)
In the preferred approach, where workers can retrieve the secret from the
master, this method should suffice even after a worker restarts. Although
this does increase the load on the master for sharing the secret, I don't
believe it worsens the situation when employed during graceful restarts.
Storing the information in LevelDB is also an option; however, since we're
storing secrets, encryption would be advisable. As it stands, even ESS
stores unencrypted secrets in LevelDB, which is unacceptable for
applications with strict security requirements.
3. In 5.a/b, what happens if two applications send the same payload? Will
they get the same shared secret?
Do you mean that two applications claim to be, let's say, AppX? If so, the
application that first registers with the master as AppX will proceed to
communicate with the Celeborn service. Once an application has registered
as AppX, the master will not permit any other application to register with
the same identifier. The master will then terminate the connection with the
second application attempting to register as AppX. That application will
not be able to connect to the service any longer, as its secret was never
registered with the master.As of now, we don't have any plans to support
TTL.
4. The doc says TTL is out of scope, is there a plan to support TTL in the
future?
No, we don't have any plans to support it as of now.
I am going to incorporate some of these points in the doc as well.
- Chandni
On Fri, Sep 15, 2023 at 10:21 PM Keyong Zhou <[email protected]> wrote:
> Hi Chandni & Mridul,
>
> Thanks for proposing this great feature! I've reviewed the design doc and
> it LGTM overall. Still I have a few questions that
> are not present in the proposal (maybe too detailed):
>
> 1. Should we store the shard secrets in Ratis among masters since leader
> may change at any time?
> 2. In case of worker graceful restart, should the worker store the shared
> secret in leveldb before it stops,
> or ask the master after it restarts? (The later seems to be necessary)
> 3. In 5.a/b, what happens if two applications send the same payload? Will
> they get the same shared secret?
> 4. The doc says TTL is out of scope, is there a plan to support TTL in the
> future?
>
> Thanks,
> Keyong Zhou
>
> Chandni Singh <[email protected]> 于2023年9月15日周五 06:34写道：
>
> > Hello Celeborn community,
> >
> > We have a proposal to add authentication to Celeborn:
> >
> >
> https://docs.google.com/document/d/1D1U2COYhS3ob7l0t2WghRhBk_Fci9RGx-2FBXA3nvXk/edit#heading=h.m97qw1fpl5kv
> >
> > Would really appreciate feedback from the community on this proposal.
> >
> > Please let me know if there is a particular format that the Celeborn
> > community follows for proposals and I will convert it into that format.
> >
> > Thank you
> > Chandni
> >
>
