The project does not recommend using insecure ports. Even
unauthenticated TLS is an improvement since it provides confidentiality.
If you relied upon this, please update to secure serving options.
Kubernetes-commit: de302c73e9558c192fde1cd7d6dcbea7eb76e950
In contrast to the original HandleError and HandleCrash, the new
HandleErrorWithContext and HandleCrashWithContext functions properly do contextual
logging, so if a problem occurs while e.g. dealing with a certain request and
WithValues was used for that request, then the error log entry will also
contain information about it.
The output changes from unstructured to structured, which might be a breaking
change for users who grep for panics. Care was taken to format panics
as similar as possible to the original output.
For errors, a message string gets added. There was none before, which made it
impossible to find all error output coming from HandleError.
Keeping HandleError and HandleCrash around without deprecating while changing
the signature of callbacks is a compromise between not breaking existing code
and not adding too many special cases that need to be supported. There is some
code which uses PanicHandlers or ErrorHandlers, but less than code that uses
the Handle* calls.
In Kubernetes, we want to replace the calls. logcheck warns about them in code
which is supposed to be contextual. The steps towards that are:
- add TODO remarks as reminder (this commit)
- locally remove " TODO(pohly): " to enable the check with `//logcheck:context`,
merge fixes for linter warnings
- once there are none, remove the TODO to enable the check permanently
Kubernetes-commit: 5a130d2b71e5d70cfff15087f4d521c6b68fb01e
This handler allows running execution prior to actual serving in a separate
goroutine when serving requests. Doing so benefits cases in serving long running
requests because it allows freeing memory used by the separate goroutine
and keeps the serving routines slim.
Signed-off-by: Eric Lin <exlin@google.com>
Kubernetes-commit: 7b2698a5e5c61b303481c2006847409fc8704746
This is a no-op change that makes the internal encryption config
hash more specific to it use and explicitly marks it as unstable.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: 9387a66c71fd85840cb199b468610b8fa950253f
Avoids starting informers or the config-consuming controller when
--enable-priority-and-fairness=false. For kube-apiserver, the config-producing controller runs if
and only if flowcontrol API storage is enabled.
Kubernetes-commit: 83f5b5c240e5cced1371bbd22e458dae43975238
This is to prevent the enablement of new data formats (CBOR) in the early stages of phased
implementation.
Kubernetes-commit: ced56a6adabdd86f99455b100b1c0c7a2b4f3c55
This change fully addresses CVE-2023-44487 and CVE-2023-39325 for
the API server when the client is unauthenticated.
The changes to util/runtime are required because otherwise a large
number of requests can get blocked on the time.Sleep calls.
For unauthenticated clients (either via 401 or the anonymous user),
we simply no longer allow such clients to hold open http2
connections. They can use http2, but with the performance of http1
(with keep-alive disabled).
Since this change has the potential to cause issues, the
UnauthenticatedHTTP2DOSMitigation feature gate can be disabled to
remove this protection (it is enabled by default). For example,
when the API server is fronted by an L7 load balancer that is set up
to mitigate http2 attacks, unauthenticated clients could force
disable connection reuse between the load balancer and the API
server (many incoming connections could share the same backend
connection). An API server that is on a private network may opt to
disable this protection to prevent performance regressions for
unauthenticated clients.
For all other clients, we rely on the golang.org/x/net fix in
b225e7ca6d
That change is not sufficient to adequately protect against a
motivated client - future changes to Kube and/or golang.org/x/net
will be explored to address this gap.
The Kube API server now uses a max stream of 100 instead of 250
(this matches the Go http2 client default). This lowers the abuse
limit from 1000 to 400.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: 800a8eaba7f25bd223fefe6e7613e39a5d7f1eeb
Instead of numerating all the etcd endpoints known by apiserver, we will
group them by purpose. `etcd-0` will be the default etcd, `etcd-1` will
be the first resource override, `etcd-2` will be the second override and
so on.
Kubernetes-commit: 03aad1f823cb719fa6e6b6d33fefa2a2140cc760
Max seats from prioriy & fairness work estimator is now min(0.15 x
nominalCL, nominalCL/handSize)
'Max seats' calculated by work estimator is currently hard coded to 10.
When using lower values for --max-requests-inflight, a single
LIST request taking up 10 seats could end up using all if not most seats in
the priority level. This change updates the default work estimator
config such that 'max seats' is at most 10% of the
maximum concurrency limit for a priority level, with an upper limit of 10.
This ensures seats taken from LIST request is proportional to the total
available seats.
Signed-off-by: Andrew Sy Kim <andrewsy@google.com>
Kubernetes-commit: d3ef2d4fe95c3ef7b1c606ad01be1183659da391
David Eads
Patrick Ohly
Anish Ramasekar
cici37
Jefftree
Jordan Liggitt
Eric Lin
Alexander Zielenski
Abu Kashem
Monis Khan
Siyuan Zhang
Nilekh Chaudhari
Ben Luddy
Yao Cheng
Rita Zhang
guangli.bao
Wojciech Tyczyński
tao.yang
Dr. Stefan Schimanski
Han Kang
seantywork
Stephen Kitt
Marek Siarkowicz
Richa Banker
Andrew Sy Kim