The following test added upstream in 1.19 fails consistently against openshift: [sig-auth] ServiceAccounts should set ownership and permission when RunAsUser or FsGroup is present [LinuxOnly] [NodeFeature:FSGroup] [Feature:TokenRequestProjection] [Suite:openshift/conformance/parallel] [Suite:k8s] Added in: https://github.com/kubernetes/kubernetes/pull/89193 Example of failure: https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/25314/pull-ci-openshift-origin-master-e2e-aws-fips/1288149961694777344 This test is skipped in origin's rule.go until a fix is available.
Failure mode: Test passes but AfterSuite fails due to the container it uses exiting non-zero.
failure context Output of node "ip-10-0-153-213.ec2.internal" pod "test-pod-5c0eadb2-cadc-4bfe-83af-f1f4bd460e5c" container "test-container": perms of file "/test-volume/token": -rw------- owner UID of "/test-volume/token": 0 owner GID of "/test-volume/token": 0 error reading file content for "/test-volume/token": open /test-volume/token: permission denied expected (hard to tell since the individual test cases don't have names but I think it is the first one): https://github.com/kubernetes/kubernetes/blob/master/test/e2e/auth/service_accounts.go#L497-L502 perms of file "/test-volume/token": -rw------- owner UID of "/test-volume/token": 1000 owner GID of "/test-volume/token": 0 content of file "/test-volume/token": <token> seems the issue is the UID of the token volume is not set as expected (0 instead of 1000) for this test case pod.Spec.SecurityContext.RunAsUser is set to 1000 and pod.Spec.SecurityContext.FSGroup is not set
Just ran against my own 4.6 cluster and the test passes. Possible a transient skew issue during the rebase. Re-enabling the test.
Issue got fixed basing on comment #3
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4196