Update the procMount test expectations to match the intentional PSA
policy relaxation introduced in commit e8bd3f629d.
As of Kubernetes 1.35+, Pod Security Admission Baseline policy
allows UnmaskedProcMount for pods with user namespaces (hostUsers:
false). This was an intentional change to support nested container
use cases while maintaining security through user namespace isolation.
The test "will fail to unmask proc mounts if not privileged" was
written before this relaxation and expected Baseline level to reject
UnmaskedProcMount. Since Baseline now allows it (for user namespace
pods), the test needs to use Restricted level instead, which
unconditionally blocks UnmaskedProcMount regardless of user namespace
settings.
Changes:
- Change PSA level from Baseline to Restricted
- Update test name to clarify it's testing Restricted level behavior
- Update framework name from "proc-mount-baseline-test" to
"proc-mount-restricted-test"
Fixes the ci-crio-userns-e2e-serial test failure that started occurring
when runtimes began reporting user namespace support.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
When proc mount is set to default, it should mask /proc.
The DefaultProcMount test was setting "hostUsers: false" which means to
create a user namespaces. This was not causing issues before, because
user namespaces was disabled by default and therefore the field was
completely ignored. Now that userns is enabled by default, the test is
failing as the runtime doesn't always have userns support.
One option would be to filter for runtimes that do have userns support.
But the default case (/proc is masked) for sure we want to test it
without userns support, as it will be applied to all pods.
To that end, we add a param "hostUsers bool" to testProcMount that will
enable it or not. Then, both test cases that call this function set it
accordingly: the default case sets it to true (no user namespace), and
the unmasked case with a privileged pod sets it to false (use a user
namespace), to verify the /proc mount is unmasked in this case.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
the exact number of lines/ro lines is not important, just that there are more than 0 ro lines
and more than 1 line total.
this helps accomodate different architectures that implement different kernel APIs
Signed-off-by: Peter Hunt <pehunt@redhat.com>
including one Alpha only test, as the feature is in alpha
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Co-authored-by: Sohan Kunkerkar <sohank2602@gmail.com>
