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