Some kernel modules are loaded from containers

Bug #1794550 reported by Cédric Jeanneret
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
Medium
Cédric Jeanneret

Bug Description

Some kernel modules are loaded from containers, and this fails when we get SELinux separation (not the case with docker so far, but podman enforces this).

Would be good to move those modprobe from containers (kolla) to t-h-t/docker/services in host_prep_tasks.

Revision history for this message
Bogdan Dobrelya (bogdando) wrote :

There was a spec for how-to load modules in containers vs hosts. I think the approach to be taken here need to be carefully examined firstly.

Changed in tripleo:
milestone: none → stein-1
Revision history for this message
Alex Schultz (alex-schultz) wrote :
Revision history for this message
Cédric Jeanneret (cjeanner) wrote :

Eeewwww...

That feature uses the fact we don't have SELinux separation.
Which is not really possible with podman, at least not as easily as docker which requires just a line in the daemon config. There might be something now with podman (not sure about the status), but I'm not sure we want to get that.

Would be good to discuss that matter. Disabling SELinux separation is a security issue (yeah, I know, already the case now) we probably don't want to push with a new container "engine".

Revision history for this message
Bogdan Dobrelya (bogdando) wrote :

The thing is, the architecture as it is referenced had been released. So this change has an upgrade impact and needs to be a full blown spec (feel free to update the podman spec submitted by Emillien). The update must include upgrade impact and corresponding compatibility testing for partners building containers and relying on the current architecture for loading kernel modules in containers

Revision history for this message
Cédric Jeanneret (cjeanner) wrote :

I'll discuss that with Emilien once he's connected. I might get a workaround that would avoid having to drop selinux separation for the "running service".

In fact, we can see two distinct things:
- modules loaded "by default" via Kolla, that I want to see out of kolla
- modules from third party available only in containers

If the first one is "easy" (currently working on it), the latter can be a bit solved with a doc update, asking to add the "security_opt: label=disable" to there container. That's an upgrade impact for sure, but a lesser than changing all the way (have to confirm this is the only change needed in such case).

That way, we stay "as is" but with some more explicit state. Guess that's for the best. Have to test/discuss a bit more :).

Revision history for this message
Jeremy Eder (jeder) wrote :

What is the specific selinux issue you're hitting?

We (in openshift engineering) are trying to arrive at a complete scope of requirements for delivering 3rd party drivers (we have 3 prototypes and all seem to be satisfied by our current design).

Revision history for this message
Cédric Jeanneret (cjeanner) wrote :

Hello Jeremy,

well, I get a "permission denied" in the audit.log, without many information.

Having worked on podman case with selinux, I discovered docker was running with no selinux process separation, while podman does enforce this by default. And that's one of the most "annoying" differences, as it makes most of the "it works with docker" fails with podman.

I'm not sure how openshift works with selinux - care to check how your container engine is running? Also, currently, tripleo (and kolla) doesn't flag any container as "infra", meaning there isn't an easy way to distinguish those needing to load modules from the others. Maybe your proto also use this feature?

You can ping me on the IRC (#tripleo - username "Tengu") if you want to discuss this a bit more actively. I'm CET though, and it's nearly the end of the day here - but if you might still catch me ;).

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to tripleo-heat-templates (master)

Reviewed: https://review.openstack.org/605450
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=9aab4de9722207034e69c07be4d63582e03f8a3e
Submitter: Zuul
Branch: master

commit 9aab4de9722207034e69c07be4d63582e03f8a3e
Author: Cédric Jeanneret <email address hidden>
Date: Wed Sep 26 17:05:57 2018 +0200

    Load iscsi_tcp module from the host.

    Until now, it's loaded from within the container, this doesn't work
    with SELinux separation.

    Change-Id: Ia2cd08b9b7950ebca4d75938ae4329641c2d6f7c
    Depends-on: Ic9076a0a1a8e1360495dcf0eb766118ec63dc362
    Related-Bug: 1794550

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/605446
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=694b8d37567cc3092823231cb2a3f0c6538da718
Submitter: Zuul
Branch: master

commit 694b8d37567cc3092823231cb2a3f0c6538da718
Author: Cédric Jeanneret <email address hidden>
Date: Wed Sep 26 16:49:25 2018 +0200

    Load ip_vs module from the host

    Currently the ip_vs module is loaded from the keepalived container,
    and if it works in a non-selinux separated env, it doesn't work with
    podman.

    Change-Id: I71e638bedde3836e05cffab53ad80bfd35313a31
    Related-Bug: 1794550

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/605452
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=c80ca5e7dc5e90b8e242fce40c684d210091678a
Submitter: Zuul
Branch: master

commit c80ca5e7dc5e90b8e242fce40c684d210091678a
Author: Cédric Jeanneret <email address hidden>
Date: Wed Sep 26 17:08:55 2018 +0200

    Load dm-multipath module from the host.

    Until now, it's loaded from within the container, this doesn't
    work with SELinux separation.

    Change-Id: I3d63d1df7496d3b8a5883b07e9d40aa21153c086
    Related-Bug: 1794550

Changed in tripleo:
milestone: stein-1 → stein-2
Changed in tripleo:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.