Let me bump this thread..see some ideas inline.
On 13 Mar 2018, at 14:07, Jakub Hrozek <jhrozek(a)redhat.com>
wrote:
> 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?
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.
> 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?