> On 20 Mar 2018, at 13:51, Simo Sorce <s...@redhat.com> wrote: > > On Tue, 2018-03-20 at 12:54 +0100, Jakub Hrozek wrote: >> Let me bump this thread..see some ideas inline.
Thank you for the prompt response. >> >>> On 13 Mar 2018, at 14:07, Jakub Hrozek <jhro...@redhat.com> wrote: >>> >>> >>> >>>> On 13 Mar 2018, at 13:42, Simo Sorce <s...@redhat.com> wrote: >>>> >>>> On Tue, 2018-03-13 at 12:05 +0100, Jakub Hrozek wrote: >>>>> Hi, >>>>> >>>>> last week, me, some other SSSD developers and Robbie looked at how the >>>>> KCM server in its current state can be debugged and what the current >>>>> issues are. One thing that stood out was that because every Kerberos >>>>> operation now requires a round-trip between libkrb5 to sssd-kcm and then >>>>> to sssd-secrets via the REST API, there are several components involved >>>>> which makes the setup brittle. In addition, the marshalling of each >>>>> request into JSON and sending it over the sssd-secrets REST API adds a >>>>> bit of an overhead. >>>>> >>>>> In a follow-up e-mail thread, Simo suggested that instead of using the >>>>> REST API, sssd-kcm might access the sssd-secrets database directly. I >>>>> wanted to discuss this potential change with the other developers. >>>>> >>>>> As I’ve been thinking about Simo’s proposal, it actually makes sense to >>>>> me. The pros and cons as I see them are: >>>>> [+] less complexity. We would get rid of the whole JSON marshalling >>>>> code and wouldn’t have to allow on a second socket-activated deamon. >>>>> [+] better performance. Again, no JSON marshalling, but in the past we >>>>> were working around the REST API not providing a PATCH verb, so KCM had >>>>> to serialize requests to make sure two concurrent PUT requests don’t >>>>> step over one another. >>>>> [+] the “proprietary” API between KCM and secrets could be augmented >>>>> more easily to allow e.g. introspection and quota management better. >>>>> We wanted to allow some form of introspection and if we confine >>>>> ourselves to the REST API, I can’t think of another way of answering “how >>>>> much of their quota is UID X using" except adding a KCM-specific REST API >>>>> endpoint anyway. >>>>> >>>>> [-] we would have to define a private API between secrets and KCM. The >>>>> REST API already has a nice router (or multiplexer if you will) to route >>>>> the different HTTP verbs into internal sssd-secrets actions, e.g HTTP GET >>>>> into retrieving a secret. >>>>> [-] overall allowing to write to the secrets database via the REST API >>>>> seems somewhat cleaner >>>>> >>>>> Are there other opinions on the matter? Should we go ahead and change the >>>>> design to write to the database directly? >>>> >>>> So one of the reasons to use secrets this way was that we could use the >>>> REST interface (with HTTPS) to route requests from a container to the >>>> host or a different node, and keep shared ccaches if needed. >>>> >>> >>> To Custodia? > > Yes > >> So, if this is a use-case you would like to keep upstream, how about we >> expose the kcm “back end” option? We could keep the current REST API code >> around, it’s tested with upstream integration tests and if we developed >> ‘local secrets’ back end, we could default to that and keep the full REST >> API as an option. > > Sure, why not. OK, I filed https://pagure.io/SSSD/sssd/issue/3685 > >>> >>>> I do not know if that's an important use case. >>> >>> My guess is “not very much” or at least I think our attempts to convince >>> people to use Kerberos with containers fell flat. > > I do not think it did, but some of these things are still getting > developed. I know kerberos is not mainstream in containers, but we did > have people asking for it in the past. > >>>> >>>> One other reason I thought was nice was that we could easily debug >>>> stuff by looking at simple text based HTTP Requests and Replies. >>>> >>>> It requires to dump or sniff the communication between kcm and secrets, >>>> but I did not think it was too hard to do ? >>> >>> The communication is already logged, the problem as far as debuggability is >>> concerned is that you need to enable debugging for two services and then >>> correlate the two log files. > > Right, and this should be simpler if KCM goes straight to the a > database, which is why I proposed it as an option, seem we agree. > >>>> >>>> If debuggability is the only issue have you thought about adding an >>>> option to dump all requests and replies from both the kcm frontend >>>> socket and the secrets backend sockets into a secure debug log file ? >>>> >>>> Would that help ? >>>> >>> >>> Yes, this would help for debuggability. There are some other issues, though: >>> >>> - the JSON marshalling, unmarshalling and talking to sssd-secrets over the >>> socket does not come for free. So we have the performance impact. I don’t >>> have numbers (because I didn’t run any comparison), but I assume there is >>> some impact. > > There is some impact in raw numbers, but ccache operations are not very > frequent, so I wonder if it really matters. You still will need some > sort of marshaling (I think) to store in a DB ? > >>> - quota reporting. We need to allow admins to show how much of the space is >>> a UID using. With the REST API, we would have to add another endpoint (GET >>> /kcm/$UID/quota_max perhaps?) and I don’t think if at that point it is >>> clean to do this because these requests can’t be forwarded to Custodia, >>> because Custodia doesn’t have a way to get the quota, right? Or do you >>> think the quota reporting can be done by talking to sssd-secrets from some >>> command line tool directly instead of the REST API? > > Yeah, dunno about this, I see the concern. But yeah some command that > goes directly to the DB (whatever the solution) seem easier to deal > with anyway, because the KCM interface itself has nothing about quotas > anyway. I guess we could extend the KCM protocol, but that would have to be done in cooperation with MIT upstream. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
