On 13 Mar 2018, at 13:42, Simo Sorce <simo(a)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?
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.
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.
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.
- 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?