9:46 a.m.
Greetings, thanks for this awesome tool and growing community!
We've been deploying podman, using systemd with podman directly (instances,
and pods), or podman kube. We've been internally talking about a couple topics
related to hardening and have been neglecting to find a place to initaite
discussion, as it's a bit meta in nature. The mailing list looks like the
right place!
Everything proposed here comes down to personal preference, but the reason we
wanted to share our discussion with the community is to explore what the sane
defaults should be for users of podman.
# rootless, rootless as non-root
Brian Smith via this video [0] uses the terminology "rootles-podman-as-non-
root". We understand that (likely niavely) to be "shifting twice":
- once from root on metal, to user on metal
- once more from root and user coliding to root in the container being
remapped off user (using subuid/subgid)
Discussion here [1] shows that if you were to attempt to user systemd-sysuers
or systemd-tmpfiles to package something (using podman) you'd not be able to
set up the subuid/subgid mappings. Poettering goes on to point out that
subuid/subgid as implemented has flaws [2].
We've been deploying as "rootless-podman-as-non-root" but have recently
been
considering removing the subuid/subgid configurations as the podman instances
for us are already running under "system" users (e.g. `/sbin/nologin`). We
can't seem to grasp the specific advantage when doing a "systems"
deplyoment,
and there is a distinct disadvantage when having to deal with file permissions
that are uid/gid shifted (pressing one to use more permissive permissions than
what would typically be necessary).
We realize that "rootless-podman-as-non-root" is valuable for things like
toolbox [3], where the example would be a non-root user wanting to run a
container mapped once again off their namespaces (e.g. a browser or something
of high risk).
# systemd unit hardening
systemd itself has a _lot_ of hardening features available [4], one can make a
unit wrapping podman and then examine it via `systemd-analyze security
unit.service`. As podman has a `podman generate systemd` it'd be extremely
interesting to have some discussion on how these features of systemd could be
enumerated/used by default.
# seccomp/eBPF/selinux
There is already some documentation on generating seccomp profiles [5], as
well as udica [6]. These seem to be very powerful tools to create instance
specific isolation for deployments. We're very interested in these, but we're
wondering how to practically apply these techniques for something that is a
complex monolithic ontainer (e.g. gitlab).
# Questions
Does the podman community have a line to the systemd community to talk about
leveraging subuid/subgid, is there a more systemd focused formalism for
accomplishing this shift?
What does the "shifting twice" accomplish for you when deploying a system
style service? (as opposed to the other hardening options mentioned below)
Will the podman community consider systemd to be a "first class" deplyoment,
and split that style of deployments into "systems" and "users" where
on
"systems" we can go far deeper into the expected defaults/patterns (toolbox
handling the "users" use case well)?
Would someone working on selinux/udica consider a complex container use case
(e.g. keycloak from RedHat itself, or gitlab as an upstream partner) for the
generation of profiles?
What are the patterns with generating profiles with udica? Would it be most
reasonable to generate these profiles on a test system, generating a profile
each time you instance the container, then deploying those profiles to
production?
We're mainly just wanting to hear from folks who are deploying podman as to
how they are using these tools, and what other tooling/techniques may be out
there that we could be looking at. Thanks for considering the inquiry!
[0]: http://www.youtube.com/watch?v=ZgXpWKgQclc&t=7m40s
[1]: https://github.com/systemd/systemd/issues/13717#issuecomment-711167021
[2]: https://github.com/systemd/systemd/issues/13717#issuecomment-539476282
[3]: https://github.com/containers/toolbox
[4]: https://www.freedesktop.org/software/systemd/man/systemd.exec.html
[5]: https://podman.io/blogs/2019/10/15/generate-seccomp-profiles.html
[6]: https://github.com/containers/udica