We were detecting the IP family that kube-proxy should use
based on the bind address, however, this is not valid when
using an unspecified address, because on those cases
kube-proxy adopts the IP family of the address reported
in the Node API object.
The IP family will be determined by the nodeIP used by the proxier
The order of precedence is:
1. config.bindAddress if bindAddress is not 0.0.0.0 or ::
2. the primary IP from the Node object, if set
3. if no IP is found it defaults to 127.0.0.1 and IPv4
Signed-off-by: Antonio Ojea <antonio.ojea.garcia@gmail.com>
Hello gophers,
Version v0.3.3 of golang.org/x/text fixes a vulnerability in the golang.org/x/text/encoding/unicode package which could lead to the UTF-16 decoder entering an infinite loop, causing the program to crash or run out of memory.
An attacker could provide a single byte to a UTF16 decoder instantiated with UseBOM or ExpectBOM to trigger an infinite loop if the String function on the Decoder is called, or the Decoder is passed to golang.org/x/text/transform.String.
transform.String has also been hardened not to enter an infinite loop if a Transformer keeps returning ErrShortSrc even if atEOF is true.
This issue was first filed as Issue 39491 by GitHub user abacabadabacaba and reported to the security team by Anton Gyllenberg. It is tracked as CVE-2020-14040.
Cheers,
Katie for the Go team
This make it easier to catch the issue during the compilation, also,
this also align with other plugins, i.e. plugin of "InterPodAffinity".
Signed-off-by: Dave Chen <dave.chen@arm.com>
This script quiently depended on being under a GOPATH, and failed
completely when it was not. This change sorts the input (to make
comparing results easier) and operates on files, rather than packages
until the last moment when we add back the package prefix.
Verified by instrumenting the code and comparing runs inside and outside
of GOPATH.
Before this commit, containers which have both a `startupProbe` and a
`readinessProbe` are marked as `ready=false` during stratup, but
containers which have only a `startupProbe` are marked `ready=true`.
This doesn't make sense.
This commit only considers readiness if the container is considered to
have "started", which leaves `ready=false` while starting up.
The behavior for exec'ing a backgrounded command is not specified
with CRI so modify the test to run the command directly instead
of using exec.
Signed-off-by: Mrunal Patel <mpatel@redhat.com>
- Refactor getNodeInfo to be more descriptive
- Add log output testing for secret update
- Ensure all nodes refreshed on secret change
- Add config option to disable secret management
