1710: selinux: Update the KEP for 1.33 and graduate to Beta

[jsafrane]

• One-line PR description: Update the KEP with current development (1.32/33) and a plan to graduate to Beta in 1.33

• Issue link: Speed up recursive SELinux label change #1710

• Other comments: See individual small commits.
  • Specify SELinux controller tests.
  • Add notes about other Linux distros (tested on Debian).
  • Add a note that the controller / KCM cannot implement SELinux label defaulting.

[gnufied]

Can you clarify which phase we will be in when this is implemented? Will - SELinuxChangePolicy will have an material effect beyond allowing users to opt-out of mount-option for applying selinux labels?

What happens if SELinuxMount is enabled (because we are moving this to beta), will SELinuxChangePolicy will then have an material impact?

[jsafrane]

I am not sure I understand. The feature gates need to be enabled in order, as described elsewhere in the KEP. Each feature gate enables a different piece of code and counts that the previous ones are enabled.

In addition, in this phase is SELinuxMount is beta, but disabled by default. "Beta" here really tells it's ready for testing,. just as we did with CSI migration and other potentially breaking changes.

I added some wording around to make it more explicit.

[gnufied]

okay, I noticed that we are already excluding pods from using mount option as selinux policy if they have SELinuxChangePolicy enabled and have opted-out of it.

So this question is kinda moot.

[kannon92]

PRR shadow:

I was reading the KEP and I think some updates for phase 1 may be needed.

https://github.com/kubernetes/enhancements/blob/fead564cd04409dc8f549ee655b3b5174c16fd29/keps/sig-storage/1710-selinux-relabeling/README.md#graduation-criteria

There is no mention of Phase 1 graduation. From the KEP issue, it sounds like you want to promote it to stable in 1.34.

[kannon92]

PRR shadow: looks good.
One item needs to be filled out.

This was tested manually before releasing SELinuxMountReadWriteOncePod enabled by default. It will be tested before SELinuxMount gets enabled by default.

[kannon92]

On a side note, what events are emitted in this case? The KEP mentions events but I didnt see what event would be emitted.

[kannon92]

And I think a prod-readiness should be updated as you are changing stage for one of the feature gates

https://github.com/kubernetes/enhancements/blob/master/keps/prod-readiness/sig-storage/1710.yaml

[jsafrane]

From the KEP issue, it sounds like you want to promote it to stable in 1.34

I updated the issue, 1.35 is the earliest and optimistic GA of SELinuxMountReadWriteOncePod + SELinuxChangePolicy. SELinuxMount at least 1 release later.

There is no mention of Phase 1 graduation.

Good catch. I added "e2e tests implemented + green".

And I think a prod-readiness should be updated as you are changing stage for one of the feature gates

I will do it in a subsequent PR, once the enhancement text is polished and merged.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jsafrane
Once this PR has been reviewed and has the lgtm label, please assign johnbelamaric for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• keps/prod-readiness/OWNERS
• keps/sig-storage/OWNERS [jsafrane]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jsafrane]

Ok, I added PRR request. We want all three feature gates beta in 1.33.

[gnufied]

from sig-storage and implementation POV. LGTM

/lgtm

[jsafrane]

I tested upgrade + downgrade + upgrade, it seems working to me.

One interesting observation is that when SELinuxChangePolicy FG got from true to false, the API server did not clear SELinuxChangePolicy field in existing Deployments (this is expected), but then when new Pods were created from these Deployments, their SELinuxChangePolicy got cleared to nil on creation (again, expected, but not obvious).

After flipping SELinuxChangePolicy back to true, the Deployments kept their SELinuxChangePolicy and newly created Pods inherited it.

Details:

1. Run today's master (491a23f) with SELinuxMount && SELinuxChangePolicy off on Fedora 41, cri-o, SELinux enforcing, enabled SELinuxWarningController, single worker node (all the pods below run on the same node!)
   SELinuxWarningController won't run, because it's behind SELinuxChangePolicy feature gate, but it's on KCM command line and we can just flip the feature gates in subsequent steps

2. Run 3 Deployments sharing the same RWO PVC in this sequence. Each has 1 replica.

   • mydeployment-priv with a Privileged Pod, no explicit SELinux label
   • mydeployment-c1 with seLinuxOpts{level:"c1,c0"} and default SELinuxChangePolicy (nil)
   • mydeployment-c2 with seLinuxOpts{level:"c2,c0"} and explicitly Recursive SELinuxChangePolicy. This is cleared to nil by the API server (SELinuxChangePolicy is off)

3. Set FG SELinuxChangePolicy: "true", SELinuxMount: "false" in KAS, KCM, scheduler and kubelet, restart them.

   • conflicting events appeared - every pod conflict with every other.

4. Set SELinuxChangePolicy of c2 and priv to Recursive

   • c1 still conflicts with c2 and priv.
   • c2 and priv do not conflict.

5. Set SELinuxChangePolicy: "true", SELinuxMount: "true" in KAS, KCM, scheduler and kubelet, restart them.

   • Depending on the order in which pods started, some Pods can get ContainerCreating (because c1 wants mount -o context=...c1,c0 and the other wants no -o context).
   • c1 still conflicts with c2 and priv.
   • c2 and priv do not conflict.

6. Set SELinuxChangePolicy: "true", SELinuxMount: "false" in KAS, KCM, scheduler and kubelet, restart them.

   • All pods are back Running.
   • Same conflict events as before

7. Set SELinuxChangePolicy: "false", SELinuxMount: "false" in KAS, KCM, scheduler and kubelet, restart them.

   • All pods Running.
   • No conflicts (no SELinuxWarningController with SELinuxChangePolicy=false

8. Set SELinuxChangePolicy: "true", SELinuxMount: "true" in KAS, KCM, scheduler and kubelet, restart them.

   • (skipping SELinuxChangePolicy: "true", SELinuxMount: "false" to save time)
   • Depending on the order in which pods started, some Pods can get ContainerCreating.
   • c1 still conflicts with c2 and priv.
   • c2 and priv do not conflict (= Deployments retained their SELinuxChangePolicy value from step 6).