b.N is adjusted by pkg/testing using an internal heuristic:
> The benchmark function must run the target code b.N times. During
> benchmark execution, b.N is adjusted until the benchmark function
> lasts long enough to be timed reliably.
Using b.N to seed other parameters makes the benchmark behavior
difficult to reason about. Before this change, thread count in the
CachedTokenAuthenticator benchmark is always 5000, and batch size is
almost always 1 when I run this locally. SimpleCache and StripedCache
benchmarks had similarly strange scaling.
After modifying CachedTokenAuthenticator to only adjust iterations based
on b.N, the batch chan was an point of contention and I wasn't able to
see any significant CPU consumption. This was fixed by using
ParallelBench to do the batching, rather than using a chan.
Kubernetes-commit: 43d34882c9b3612d933b97b6e470fd8d36fe492b
It is possible to configure the token cache to cache failures. We
allow 1 MB of headers per request, meaning a malicious actor could
cause the cache to use a large amount of memory by filling it with
large invalid tokens. This change hashes the token before using it
as a key. Measures have been taken to prevent precomputation
attacks. SHA 256 is used as the hash to prevent collisions.
Signed-off-by: Monis Khan <mkhan@redhat.com>
Kubernetes-commit: 9a547bca8e6e15273bfafd3496aa6524fd7d35bd
The striped cache used by the token cache is slightly more sophisticated
however the simple cache provides about the same exact behavior. I used
the striped cache rather than the simple cache because:
* It has been used without issue as the primary token cache.
* It preforms better under load.
* It is already exposed in the public API of the token cache package.
Kubernetes-commit: 0ec4d6d396f237ccb3ae0e96922a90600befb83d
Mike Danese
Daniel Smith
Monis Khan
Jordan Liggitt