We have an SCC-exec admission plugin in the OpenShift kube-apiserver that is intended to prevent users from execing into pods they cannot create. This works well with "CREATE pods/exec" calls. However, we potentially have a vulnerability on "pods/exec" with clients using websockets: Client can use webhook to exec into a Pod, and the http verb must be GET, because websocket RFC dictates that handshake must be done using GET verb: see https://www.rfc-editor.org/rfc/rfc6455#section-1.2 ( https://github.com/kubernetes/kubernetes/issues/78741 has more details) OpenShift SCC-exec admission plugin in the kube-apiserver cannot handle this case because admission is never called on GET requests. Currently in OpenShift a user (who does not have "create Pod" privilege in his/her namespace) with a "CREATE pods/exec" request will be prevented from exec-ing into the privileged pods. However, if the same user issues a "GET pods/exec" request into the same privileged pod, the SCC-exec admission plugin will be bypassed and the user will be allowed to exec into the privileged pod. Please let us know if you need any help in reproducing the issue and assessing its impact
Created golang-k8s-kubernetes tracking bugs for this issue: Affects: fedora-36 [bug 2153803] Affects: fedora-37 [bug 2153805] Created origin tracking bugs for this issue: Affects: fedora-36 [bug 2153804] Affects: fedora-37 [bug 2153806]
Created golang-k8s-kubernetes tracking bugs for this issue: Affects: fedora-36 [bug 2153807] Affects: fedora-37 [bug 2153809] Created origin tracking bugs for this issue: Affects: fedora-36 [bug 2153808] Affects: fedora-37 [bug 2153810]
As mentioned in the upstream kubernetes issue[0], it has been known for some time that both "get" and "create" verb permissions allow authorized users to complete "pod/exec" calls. In upstream docs[1], "get" verb maps to HTTP GET and "create" maps to HTTP POST. The command-line utils `kubectl exec` and `oc exec` use create/POST to initiate "pod/exec" calls, which are upgraded to SPDY connections. To support Websocket connections (e.g. via browser/webconsole), which are initiated by HTTP GET, the "get" verb also allows authorized users to complete "pod/exec" calls (see detailed example[2]). This behaviour has been documented in OpenShift for some time[3], to prevent users from completing "pod/exec" calls all verbs should be removed from that respective user's RBAC. As written, this flaw seems to be specific to the the SCC-exec admission plugin[4], which is an OpenShift-only inclusion (i.e. not part of upstream Kubernetes) that prevents users from completing "pod/exec" calls into pods that they would not be able to create. As admission plugins are not called on GET requests, this admission plugin does work on Websocket connections for "pod/exec" calls. As users still need to be granted the "get" permission with "pod/exec", the "bypass" here is relatively minor, as in this regard OpenShift is behaving the same as upstream Kubernetes. However, it seems that the OpenShift SCC-Exec admission plugin has a gap in coverage (or at least expectations). That said, I'm also not sure what a feasible solution might look like. I don't think that an Important severity rating is warranted here, I'm also not completely convinced a CVE assignment is the right course of action either. An enhancement / weakness / hardening bug might have been a better way to track this. [0] https://github.com/kubernetes/kubernetes/issues/78741 [1] https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb [2] https://gist.github.com/sfowl/d0377328e64a00797c2bf454ab34d97d [3] https://docs.openshift.com/container-platform/4.8/rest_api/workloads_apis/pod-core-v1.html#apiv1namespacesnamespacepodsnameexec [4] https://github.com/openshift/apiserver-library-go/blob/master/pkg/securitycontextconstraints/sccadmission/scc_exec.go#L36