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?
Thanks!
Justin
On 3/11/20 2:58 PM, Brian Bouterse wrote:
On Wed, Mar 11, 2020 at 2:34 PM Justin Sherrill <jsher...@redhat.com
<mailto:jsher...@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 list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
