On Tue, 2018-03-20 at 12:54 +0100, Jakub Hrozek wrote:
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?
Yes
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.
Sure, why not.
>
> > 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.
I do not think it did, but some of these things are still getting
developed. I know kerberos is not mainstream in containers, but we did
have people asking for it in the past.
> >
> > 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.
Right, and this should be simpler if KCM goes straight to the a
database, which is why I proposed it as an option, seem we agree.
> >
> > 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.
There is some impact in raw numbers, but ccache operations are not very
frequent, so I wonder if it really matters. You still will need some
sort of marshaling (I think) to store in a DB ?
> - 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?
Yeah, dunno about this, I see the concern. But yeah some command that
goes directly to the DB (whatever the solution) seem easier to deal
with anyway, because the KCM interface itself has nothing about quotas
anyway.
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc