tomcat-only, linux, non-root

[Peter Schober]

* Etienne Dysli-Metref <etienne.dysli-metref at switch.ch> [2016-08-11 14:21]:
> On 11/08/16 11:37, Etienne Dysli-Metref wrote:
> > Thank you for linking to the "systemd house of horror"! :) That's one of
> > my current favourites. Too bad it fell off the web.
> 
> And has reappeared! -> http://jdebp.eu/FGA/systemd-house-of-horror/

Thanks, I've updated the link in the wiki page.

I've added a link to an example of dynamic iptables/firewalld rules
generation from within a systemd unit file, making the point of "lost"
or simply unavailable iptables rules much less vile (for the "port
forwarding" method).

The same method has now been incorporated into the POSIX capabilities
approach, setting (and removing) the capabilities on startup via an
amended (included, and fully tested for CentOS7) systemd unit file --
replacing the previously mentioned inotify/incrond approach.
(This is now the simplest b/c most direct approach of all, I think.)

I've also added a new (but partially still rough) section on
"Proxying" approaches, which may not be recommended but still seem to
be popular (e.g. fronting with httpd or a TLS offloading
loadbalancer). Hashing out the details and differences in the variants
more clearly (what process listens where, who proxies to where
how/why) would be useful, I think.
Anyway, that last section now also contains a general write-up of the
systemd-socket-proxyd approach, though I have not yet tested this
myself (which is why no tested systemd files are included yet).

One thing I'm not quite happy about is the structure of the content:
All methods except "Apache httpd and Tomcat"/"Webservers without AJP
support" work *without* an extra server/daemon on the IDP machine
(ignoring jsvc and systemd-socket-proxyd here), and so are fully
usable with only running the container as the only web server process:
* port forwarding
* authbind
* capabilities
* external/existing loadbalancer/TLS offloader
* systemd-socket-proxyd

The "extra webserver on the same machine" approach seems the most
popular way to run the container as non-root, but it's also the most
heavy-weight and configuration/integration-intensive approach.
Compare this with a simple systemd unit file that creates iptables or
capability assignments as needed on container startup and changes
exactly NOTHING wrt the way the container needs to be configured: "You
want to expose a TLS-enabled webserver on port 443? Have it listen on
port 443. You want a backchannel on port 8443? Have it listen on port
8443. You're done."
If you look at the prose I added to the "Proxying" section you see I'm
struggling for sanity. (At least I felt I was.)

-peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://shibboleth.net/pipermail/users/attachments/20160811/2a1b4bc8/attachment-0001.sig>