adds an alpha AuthorizeNodeWithSelectors feature that makes the node authorizer limit requests from node API clients to get / list / watch its own Node API object, and to get / list / watch its own Pod API objects. Clients using kubelet credentials to read other nodes or unrelated pods must change their authentication credentials (recommended), adjust their usage, or grant broader read access independent of the node authorizer. ([#125571](https://github.com/kubernetes/kubernetes/pull/125571), [@...

					}
				}
				if reader != nil && proxy.Proxy && perr == nil {
					gr = reader
				}
			}
		}
		if reader == nil || !proxy.Proxy {
			// validate if the request indeed was authorized, if it wasn't we need to return "ErrAccessDenied"
			// instead of any namespace related error.
			if s3Error := authorizeRequest(ctx, r, policy.GetObjectAction); s3Error != ErrNone {

    server.enqueue(MockResponse(body = "this response comes via HTTPS"))
    server.enqueue(MockResponse(body = "another response via HTTPS"))

    // install a custom SSL socket factory so the server can be authorized
    client =
      client
        .newBuilder()
        .sslSocketFactory(
          handshakeCertificates.sslSocketFactory(),
          handshakeCertificates.trustManager,

### CVE-2022-3162: Unauthorized read of Custom Resources

A security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group they are not authorized to read.

**Affected Versions**:
  - kube-apiserver v1.25.0 - v1.25.3
  - kube-apiserver v1.24.0 - v1.24.7

object by patching themselves with an OwnerReference to a cluster-scoped resource. If the OwnerReference resource does not exist or is subsequently deleted, the given node object will be deleted via garbage collection. By default, node users are authorized for create and patch requests but not delete requests against their node object. Since the NodeRestriction admission controller does not prevent patching OwnerReferences, a compromised node could leverage this vulnerability to delete and then recreate...

* Fix working_set calculation in kubelet ([#29153](https://github.com/kubernetes/kubernetes/pull/29153), [@vishh](https://github.com/vishh))
* Fix RBAC authorizer of ServiceAccount ([#29071](https://github.com/kubernetes/kubernetes/pull/29071), [@albatross0](https://github.com/albatross0))

### CVE-2022-3162: Unauthorized read of Custom Resources

A security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group they are not authorized to read.

**Affected Versions**:
  - kube-apiserver v1.25.0 - v1.25.3
  - kube-apiserver v1.24.0 - v1.24.7

- Fixed an issue where the `vsphere` cloud provider would not trust a certificate if:
  - The issuer of the certificate was unknown (`x509.UnknownAuthorityError`)
  - The requested name did not match the set of authorized names (`x509.HostnameError`)

Kube-apiserver: Added support for disabling caching of authorization webhook decisions in the `--authorization-config` file. The new fields `cacheAuthorizedRequests` and `cacheUnauthorizedRequests` could be set to `false` to prevent caching for authorized or unauthorized requests. See the https://kubernetes.io/docs/reference/access-authn-authz/authorization/#using-configuration-file-for-authorization for more details. ([#129237](https://github.com/kubernetes/kubernetes/pull/129237), [@rfranzke](...

- LimitRange and Endpoints resources can be created via an update API call if the object does not already exist. When this occurs, an authorization check is now made to ensure the user making the API call is authorized to create the object. In previous releases, only an update authorization check was performed. ([#65150](https://github.com/kubernetes/kubernetes/pull/65150), [@jennybuckley](https://github.com/jennybuckley))