Change:
/kind cleanup /area conformance /area test /sig node /sig testing /sig architecture /assign /assign We have a number of tests that only have the tag that may make sense as tests, we should identify whether these tests cases meet (or could meet) the . We should open PR's to promote these if so. I would advise starting with the test/common cases
GitHub didn't allow me to assign the following users: mgdevstack, mkurylec. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /kind cleanup /area conformance /area test /sig node /sig testing /sig architecture /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
The tests in test/e2enode don't actually get run as part of Conformance as near as I can tell. If we want to run them as part of conformance, they need to be migrated into test/e2e/common. Some of the tests in e2enode may not be able to be ported over because they assume a level access we don't have in a conformance environment.
regarding this testcase: [sig-storage] HostPath should support r/w [NodeConformance]: It uses hostPath and privileged=true, to read/write from /tmp folder. Which would you suggest is the best orientation to overcome the privilege mode setting and allow its promotion?
/assign
Regarding , the suite runs the test only if the kubelet configuration was required to have the QOS (cgroups-per-qos) enabled. This configuration for the kubelet is selected at the time the cluster is set up. Looking for where this might be configured found: where is set to true. For other settings it is also configured to true. where is set to true. BUT also found where it is mentioned that the flag is no longer available. Questions: would it be ok to promote this test to be conformance, even it can be skipped based on configuration of the cluster? And not supported in the containerized kubelet?
I would consider cgroups to be an implementation detail that Conformance shouldn't be verifying
It uses hostPath and privileged=true, to read/write from /tmp folder. Which would you suggest is the best orientation to overcome the privilege mode setting and allow its promotion? Michelle Au If my understanding is correct, on some platforms, writing to /tmp requires privileged. I don't see a way to to remove that requirement.
If my understanding is correct, on some platforms, writing to /tmp requires privileged. I don't see a way to to remove that requirement. Yeah writing to host doesn't seem like a thing we can expect of conformance tests. I wonder if it makes sense to tag this test with something to denote the requirement, ie: I see some tests in test/e2e_node use
The hostpath tests in already have a comment explaining this. Maybe the comment should be updated to be more clear that that is the reason why we can't add it to conformance.
That's /tmp on the host or in the container filesystem?
/tmp on the host
ping what else remains to be done before we close this out? I am guessing that we want to close , is there anything beyond that?
Once tests under (issue- ) and are promoted we are good to close this issue. Short update for reference- None of [NodeConformance] tests from "test/e2e_node" seems eligible for [Conformance] promotion at this moment due to node level dependencies. Remaining [NodeConformance] tests from "test/e2e" has following status - Waiting for to be closed and then below tests would be promoted to Conformance Needs to be Promoted Can not be promoted to Conformance as //Slow by design Can not be promoted due to Node level dependency
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/lifecycle frozen
/assign

Discussion:
test/e2e/common/secrets_volume.go: "should be able to mount in a volume regardless of a different secret existing with same name in different namespace" test/e2e/common/secrets_volume.go: "should be consumable in multiple volumes in a pod" test/e2e/common/secrets_volume.go: "optional updates should be reflected in volume" <ins> test/e2e/common/security_context.go: "should run the container with uid 65534" test/e2e/common/security_context.go: "should run the container with writable rootfs when readOnlyRootFilesystem=false" test/e2e/common/security_context.go: "should run the container as unprivileged when false" test/e2e/common/security_context.go: "should not allow privilege escalation when false" </ins> test/e2e/kubectl/kubectl.go: "should create and stop a replication controller" test/e2e/kubectl/kubectl.go: "should scale a replication controller" test/e2e/kubectl/kubectl.go: "should do a rolling update of a replication controller"

} /* <del> Release : v1.12 Testname: Security Context: runAsUser (id:65534) Description: Container created with runAsUser option, passing an id (id:65534) uses that given id when running the container. This test is marked LinuxOnly since Windows does not support running as UID / GID. </del> <ins> Release : v1.15 Testname: Security Context, runAsUser=65534 Description: Container is created with runAsUser option by passing uid 65534 to run as unpriviledged user. Pod MUST be in Succeeded phase. [LinuxOnly]: This test is marked as LinuxOnly since Windows does not support running as UID / GID. </ins> */ <del> It("should run the container with uid 65534 [LinuxOnly] [NodeConformance]", func() { </del> <ins> framework.ConformanceIt("should run the container with uid 65534 [LinuxOnly] [NodeConformance]", func() { </ins> createAndWaitUserPod(65534) }) /* <del> Release : v1.12 Testname: Security Context: runAsUser (id:0) Description: Container created with runAsUser option, passing an id (id:0) uses that given id when running the container. This test is marked LinuxOnly since Windows does not support running as UID / GID. </del> <ins> Release : v1.15 Testname: Security Context, runAsUser=0 Description: Container is created with runAsUser option by passing uid 0 to run as root priviledged user. Pod MUST be in Succeeded phase. This e2e can not be promoted to Conformance because a Conformant platform may not allow to run containers with 'uid 0' or running privileged operations. [LinuxOnly]: This test is marked as LinuxOnly since Windows does not support running as UID / GID. </ins> */ It("should run the container with uid 0 [LinuxOnly] [NodeConformance]", func() { createAndWaitUserPod(0)

} /* <del> Release : v1.12 Testname: Security Context: readOnlyRootFilesystem=true. Description: when a container has configured readOnlyRootFilesystem to true, write operations are not allowed. This test is marked LinuxOnly since Windows does not support creating containers with read-only access. </del> <ins> Release : v1.15 Testname: Security Context, readOnlyRootFilesystem=true. Description: Container is configured to run with readOnlyRootFilesystem to true which will force containers to run with a read only root file system. Write operation MUST NOT be allowed and Pod MUST be in Failed state. At this moment we are not considering this test for Conformance due to use of SecurityContext. [LinuxOnly]: This test is marked as LinuxOnly since Windows does not support creating containers with read-only access. </ins> */ It("should run the container with readonly rootfs when readOnlyRootFilesystem=true [LinuxOnly] [NodeConformance]", func() { createAndWaitUserPod(true) }) /* <del> Release : v1.12 Testname: Security Context: readOnlyRootFilesystem=false. Description: when a container has configured readOnlyRootFilesystem to false, write operations are allowed. </del> <ins> Release : v1.15 Testname: Security Context, readOnlyRootFilesystem=false. Description: Container is configured to run with readOnlyRootFilesystem to false. Write operation MUST be allowed and Pod MUST be in Succeeded state. </ins> */ <del> It("should run the container with writable rootfs when readOnlyRootFilesystem=false [NodeConformance]", func() { </del> <ins> framework.ConformanceIt("should run the container with writable rootfs when readOnlyRootFilesystem=false [NodeConformance]", func() { </ins> createAndWaitUserPod(false) }) })

podClient.WaitForSuccess(podName, framework.PodStartTimeout) return podName } <del> It("should run the container as unprivileged when false [LinuxOnly] [NodeConformance]", func() { // This test is marked LinuxOnly since it runs a Linux-specific command, and Windows does not support Windows escalation. </del> <ins> /* Release : v1.15 Testname: Security Context, privileged=false. Description: Create a container to run in unprivileged mode by setting pod's SecurityContext Privileged option as false. Pod MUST be in Succeeded phase. [LinuxOnly]: This test is marked as LinuxOnly since it runs a Linux-specific command. */ framework.ConformanceIt("should run the container as unprivileged when false [LinuxOnly] [NodeConformance]", func() { </ins> podName := createAndWaitUserPod(false) logs, err := framework.GetPodLogs(f.ClientSet, f.Namespace.Name, podName, podName) if err != nil {

} /* <del> Testname: allowPrivilegeEscalation unset and uid != 0. Description: Configuring the allowPrivilegeEscalation unset, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation not specified (nil) and a given uid which is not 0. When the container is run, the container is run using uid=0. This test is marked LinuxOnly since Windows does not support running as UID / GID, or privilege escalation. </del> <ins> Release : v1.15 Testname: Security Context, allowPrivilegeEscalation unset, uid != 0. Description: Configuring the allowPrivilegeEscalation unset, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation not specified (nil) and a given uid which is not 0. When the container is run, container's output MUST match with expected output verifying container ran with uid=0. This e2e Can not be promoted to Conformance as it is Container Runtime dependent and not all conformant platforms will require this behavior. [LinuxOnly]: This test is marked LinuxOnly since Windows does not support running as UID / GID, or privilege escalation. </ins> */ It("should allow privilege escalation when not explicitly set and uid != 0 [LinuxOnly] [NodeConformance]", func() { podName := "alpine-nnp-nil-" + string(uuid.NewUUID())

}) /* <del> Testname: allowPrivilegeEscalation=false. Description: Configuring the allowPrivilegeEscalation to false, does not allow the privilege escalation operation. A container is configured with allowPrivilegeEscalation=false and a given uid (1000) which is not 0. When the container is run, the container is run using uid=1000. This test is marked LinuxOnly since Windows does not support running as UID / GID, or privilege escalation. </del> <ins> Release : v1.15 Testname: Security Context, allowPrivilegeEscalation=false. Description: Configuring the allowPrivilegeEscalation to false, does not allow the privilege escalation operation. A container is configured with allowPrivilegeEscalation=false and a given uid (1000) which is not 0. When the container is run, container's output MUST match with expected output verifying container ran with given uid i.e. uid=1000. [LinuxOnly]: This test is marked LinuxOnly since Windows does not support running as UID / GID, or privilege escalation. </ins> */ <del> It("should not allow privilege escalation when false [LinuxOnly] [NodeConformance]", func() { </del> <ins> framework.ConformanceIt("should not allow privilege escalation when false [LinuxOnly] [NodeConformance]", func() { </ins> podName := "alpine-nnp-false-" + string(uuid.NewUUID()) apeFalse := false if err := createAndMatchOutput(podName, "Effective uid: 1000", &apeFalse, 1000); err != nil {

}) /* <del> Testname: allowPrivilegeEscalation=true. Description: Configuring the allowPrivilegeEscalation to true, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation=true and a given uid (1000) which is not 0. When the container is run, the container is run using uid=0 (making use of the privilege escalation). This test is marked LinuxOnly since Windows does not support running as UID / GID. </del> <ins> Release : v1.15 Testname: Security Context, allowPrivilegeEscalation=true. Description: Configuring the allowPrivilegeEscalation to true, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation=true and a given uid (1000) which is not 0. When the container is run, container's output MUST match with expected output verifying container ran with uid=0 (making use of the privilege escalation). This e2e Can not be promoted to Conformance as it is Container Runtime dependent and runtime may not allow to run. [LinuxOnly]: This test is marked LinuxOnly since Windows does not support running as UID / GID. </ins> */ It("should allow privilege escalation when true [LinuxOnly] [NodeConformance]", func() { podName := "alpine-nnp-true-" + string(uuid.NewUUID())