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. I do not know if that's an important use case. 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 ? 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 ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
