[Pulp-dev] Moving Content Guard Authorization to Webserver and out of pulp-content

[Brian Bouterse]

On Wed, Mar 11, 2020 at 9:18 PM Justin Sherrill <jsherril at redhat.com> wrote:

> Thanks and it does appears that we use certs that could be too large for
> default header sizes (by several multiples).
>
> Could you elaborate a bit about the design a bit more?  I'm curious what
> the requirements of web service layer (will it need to talk to the pulp3
> api? the db?)  Will it just add some header after reading the cert (and
> validating the path) and then pass it on to the reverse proxy with apache?
>
This was the idea, but in looking through the nginx and apache
documentation it doesn't seem possible. I had planned to use
WSGIAccessScript, but the pulp-content app isn't wsgi it's ProxyPass so I
don't see an access script option for that which means my plan isn't
achievable as is. At best nginx has the auth request model
https://nginx.org/en/docs/http/ngx_http_auth_request_module.html but that
makes a subrequest and apache doesn't support it. We'd still have the
"certs are too big for headers" problem to deal with. I'm configuring nginx
and http and doing some testing. Articles are saying the header options
would work for both nginx and httpd, so I'm going to do some testing with
their configs. https://connect2id.com/products/server/docs/guides/tls-proxy

I'll post my findings and bump this list also for more input.

> Thanks!
>
> Justin
> On 3/11/20 2:58 PM, Brian Bouterse wrote:
>
>
>
> On Wed, Mar 11, 2020 at 2:34 PM Justin Sherrill <jsherril at redhat.com>
> wrote:
>
>> We had discussed base64 encoding the cert in the webserver on the way in
>> and then letting cert guard decode it.  While that's not ideal I think it
>> has some advantages over moving the full auth into the webserver.  What was
>> your motivation for going with that approach over the base64 encoding
>> approach?
>>
> Thank you for this question! I ended up with a few different concerns
> about the base64 encode-and-forward idea. Architecturally the concern with
> it is that it's frowned upon to forward the client's TLS cert beyond the
> TLS termination point because that is what MITM software does. Also, there
> are some practical concerns: one, I don't think nginx can provide a similar
> runtime base64 encoding feature. Also I was concerned with header length
> truncation and what happens when the certificates get longer.
>
> Overall having auth that is based on TLS certificates brought me to the
> conclusion that we need to auth where the TLS is terminated. What do you
> think?
>
> More thoughts and questions are welcome. This is a good discussion.
>
> On 3/11/20 2:11 PM, Brian Bouterse wrote:
>>
>> tl;dr: What we have today cannot work with rhsm certificates which
>> Katello uses. To resolve, we need to have content guard checking moved to
>> the webserver configs for apache and nginx and not done in pulp-content as
>> it is today.  https://pulp.plan.io/issues/6323
>>
>> We need to bring the auth to where TLS is terminated because we can't
>> being the client certs to pulp-content due to invalid header characters. As
>> is, pulp-certguard cannot work with Katello's cert types (rhsm certs) so
>> that is driving my changes.
>>
>> If anyone has major concerns or other ideas please let me know. In the
>> meantime I'm proceeding moving the authorization to the webserver and then
>> updating pulp-certguard to work with that. This will make pulp-certguard's
>> GA tied to pulpcore 3.3.0. Feedback is welcome.
>>
>> [0]: https://pulp.plan.io/issues/6323
>>
>> Thanks,
>> Brian
>>
>>
>> _______________________________________________
>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200312/7e1551a3/attachment.htm>