> 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?

> 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 

 - 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?
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to