Running Rook/Ceph with SELinux Policies, not with Privileged Pods

[KKonak]

I am trying to run Rook/Ceph with SELinux enforcing, I was successful setting the parameter in the helm chart "hostpathRequiresPrivileged" to get it working. But I am wanting to use it with a SELinux policy that restricts Rook/Ceph access to just what it needs to function.

I am not well versed in creating SELinux policies so I have been exploring different policy generators, but I'm wondering if Rook provides an SELinux policy that I couldnt find in the repo. Or if someone has had success in creating a policy I would appreciate some assistance.

[travisn]

There is not a more specific policy for the same.

[KKonak]

Running ceph pods as privleged isnt exactly good security posture. Are there any plans to provide SELinux policies in the future?
Perhaps you could explain what "hostpathRequiresPrivleged" does under the hood? Is it giving privilege to just access the host path or to all pod processes? Thank you for the response.

[travisn]

Are you running in OpenShift or another environment with SELinux enabled? For OpenShift, we have the SecurityContextConstraints. One of the core needs for privileged access is access to /dev, and the data stored to the host path for mons. We are open to contributions in this area if you have specific suggestions.

[KKonak]

Thanks for the information, I am running an environment with SELinux enabled as a requirement. I have created a working starter policy that applies to container_t context. Now I want to label rook/ceph pods with its own custom source context (so my policies arent applied to all pods with container_t).

In the rook-ceph-values.yaml "containerSecurityContext" is an option which I presumed would have the k8s native "seLinuxOptions" field to label the container with a source context. Would this be a reasonable addition to add to the helm charts to make labeling easier so it can be configured for seLinux environments?

[travisn]

The containerSecurityContext only applies to the operator and toolbox pods, but at least it should already support the full securityContext options such as seLinuxOptions.

For all the ceph pods, the only security context currently applied is found in these helper methods, which don't have a way to override from the CR settings. Seems like we need a seLinuxOptions setting in the CephCluster CR to allow setting this (and the helm chart would also inherit this setting).

[KKonak]

Okay I've gathered that thank you! Im currently working on patching those helper methods in controller/spec.go so its good to know im on the right track to labeling them properly. Am I correct in seeing that controller deploys mons and mgr then the osd spec.go handles labeling those pods here?

If rook could add an seLinuxOptions setting that would be a great addition for the future, so in future versions we dont have to look through and repatch the go files.

Thank you for your responses, this dialogue has been a great help.

[travisn]

The OSD pods have several init containers, as you see that one specifically requests a different context.

[KKonak]

For documentation and to help others, can confirm success with patching helper methods like so:

func PodSecurityContext() *v1.SecurityContext {
    privileged := HostPathRequiresPrivileged()

    return &v1.SecurityContext{
        Privileged: &privileged,
        SELinuxOptions: &v1.SELinuxOptions{
            Type: "rook_ceph_t",
        },
    }
}

The ceph pods seem to deploy now with the custom context.