Bump ip-masq-agent version to v2.3.0

[anfernee]

Fixed vulnerabilities:
CVE-2018-15688 CVE-2017-15670 CVE-2017-18269 CVE-2017-16997 CVE-2017-15804 CVE-2018-18311 CVE-2018-18312 CVE-2018-18314 CVE-2017-1000408

Bump ip-masq-agent version to v2.3.0 to fix vulnerabilities

[anfernee]

/test pull-kubernetes-integration

[bowei]

/lgtm

[tpepper]

/kind feature

[tpepper]

So we're basically reopening #77458 and calling it a security fix now?

[tpepper]

/kind bug

I haven't been able to get any interaction with the author of this PR, but @aleksandra-malinowska has noted the "feature" portion of the prior PR is actually removed here. I'm willing to treat this as a bug fix.

It still does not meet merge criteria though lacking full lgtm/approved labelling from SIG approvers.

[anfernee]

Sorry for the late response. #77458 changes the behavior of ip-masq-agent, but this simply bumps the image version.

[bowei]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anfernee, bowei

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cluster/addons/ip-masq-agent/OWNERS [bowei]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tpepper]

To update this set of cherry pick PRs (#77834, #77833, and #77832 against 1.12, 1.13, and 1.14 respectively):

As a member of the @kubernetes/patch-release-team, I had previously objected to similar cherry picking (#77572) as it was coupled to a vendor specific feature and did not meet the criteria for cherry pick. ip-masq-agent was bumped for the purpose of enabling a feature and that was rejected.

So in the meantime the submitters seem to have realized there are critical CVEs which should be fixed and that does the bulk of what they'd need coincidentally to add their feature (though that specific feature portion would exist on some branch they control not in the upstream project 1.12/1.13/1.14 release streams). I feel like the system may be being gamed here, I worry about the precedent that would set, and I wonder whether we should reject this set of PRs and ask for just the bug fixes on a 2.0.Z or 2.1.Z release stream.

Despite the poor optics and since the current set of PRs has been decoupled from the feature with the sub-portion of the prior PR attempt now presented as just a bug fix incrementing the minor version of a dependency to bring in CVE fixes that are given lgtm/approve by the appropriate OWNERS that we can approve the cherry pick. It's just unfortunate for this to play out this way and it is something that should be avoided in the future.

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.