Add enhancement proposal for selinux-operator #327
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: JAORMX The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
JAORMX
force-pushed
the
selinux-operator
branch
2 times, most recently
from
fd13cc2
to
78df048
Compare
There was a problem hiding this comment.
I like this idea. One thing that hits me though is exposing SELinux at the cluster level makes sense, but SELinux is not the most user unfriendly thing. I'd love a future one to have the groupings of policies that can be reused -- or something else that makes the configuration feel less like modifying hosts (even though that's what's happening under the covers). Just a thought.
One question is around why we'd do this without modifying the MachineConfig. Is this to avoid rebooting?
| Provide a way for deployers to install, remove and audit SELinux policies for | ||
| containers in the cluster. | ||
|
|
||
| ### Non-Goals |
Right, so that definitely plays into this. The worklow is as follows:
We wouldn't want the nodes to have to restart before you can run your pod. On the other hand, we don't really persist files directly into the host with this. The CIL file is just taken into use by the |
There was a problem hiding this comment.
The use cases around SELinux are also very similar to what you may see with seccomp profile distribution. There is a proposal for a seccomp operator to distribute seccomp profiles in SIG Node upstream as a new sub-project. If you could describe why the MCO is unable to meet the need to distribute this information, and if it was evaluated and rejected, please add that to this proposal.
/cc @mrunalp
| * `status.usage`: This string indicates how the user is supposed to use this | ||
| policy in their `Pod` templates. The format is as follows: | ||
| `<policy name>_<policy namespace>.process>` | ||
| * `status.state`: This represents the current status of the policy in the |
There was a problem hiding this comment.
what does status.state mean if the cluster is autoscaled? is the state actually installed until the the daemonset is scheduled to that new node and rendering its value? if this was driven through MCO, we have a way of knowing if a change is applied across a whole pool of nodes.
There was a problem hiding this comment.
The installation is managed via a DaemonSet. If you scale your nodes, the daemonset scales too. so those nodes should get the policy as well.
| `<policy name>_<policy namespace>.process>` | ||
| * `status.state`: This represents the current status of the policy in the | ||
| cluster. The accepted states are: `PENDING`, `IN-PROGRESS`, `INSTALLED`, | ||
| `ERROR`. A typical reason why a policy would end up in an ERROR state would |
There was a problem hiding this comment.
when is this validation performed? is this asserting that validation is done not at admission time?
There was a problem hiding this comment.
Right, it's not done at admission time. It could! I just haven't coded that yet.
| * Given that this uses a custom operator and a custom resource, integration | ||
| with `Pods` and standard kubernetes resources doesn't necessarily use the | ||
| same names (e.g. why the `usage` section was needed in the first place). In | ||
| the future, we could consider adding a section to the `seLinuxOptions` |
There was a problem hiding this comment.
this would require a change upstream k8s itself, right? is it better to explore this upstream similar to the seccomp proposed sub-project?
There was a problem hiding this comment.
This could be an option. However, I decided to post this here first cause it's better to first show something that's working and gain adoption, before trying to submit it there. SELinux is not available for all kube distros after all.
|
Is there a reason why we would not want this API to be part of the machine config operator? So a higher-level domain specific API, but still coordinated via a common delivery mechanism. |
We wouldn't persist the policy files on the host, these get compiled and installed via SELinux utilities. So it wouldn't be able to use the same delivery mechanism that Machineconfig provides. |
This operator aims to simply the installation, usage, removal and auditing of SELinux policies at a cluster level.
|
cc: @rhatdan |
@mrunalp do you have a link to that enhancement or docs? I could add support for adding a "nodeSelector" to the policy Custom Resource, so it would only get installed in the nodes that are specified. This way, you could tell it to only install it on nodes that have kata (when needed). Note that this is also meant to address non-kata cases, so it would be useful without kata still. |
|
@JAORMX It went into containers-selinux in containers/container-selinux@b321ea4 and follow on PRs. I am more wondering here whether that should be split out to be an optional policy that we only install on kata nodes. Thanks! |
|
No reason to make this an optional policy. It is in the base and will be used by Podman also. I would think the selinux-operator would be for custom user policy not for something that is in the base system. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci-robot
removed
the
lifecycle/stale
openshift-ci-robot
added
the
lifecycle/rotten
|
/remove-lifecycle rotten |
openshift-ci-robot
removed
the
lifecycle/rotten
|
/hold I'll get back to this soon. I'm gonna do a bit more user-research to present more solid use-cases here. |
openshift-ci-robot
added
the
do-not-merge/hold
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
This operator aims to simply the installation, usage, removal and
auditing of SELinux policies at a cluster level.