contour
contour copied to clipboard
projectcontour
Providing security notifications for previous releases
This issue comes from yesterdays community discussion regarding challenges in providing security updates separate from feature updates.
The summary of the issue is that there are challenges providing security only updates as many Envoy security fixes modify features. This requires Contour to add / change features to fix security issues, this does not allow a disconnect between security and feature updates.
I think a reasonable approach is to create a 'check update' package. This package will be deployed with it's own container as a Kubernetes cron job, this is an optional part of the Contour deployment.
Base functionality:
The package checks the current running version of Contour and the latest release version from github. If the Current deployed version if not on the latest then a warning message is returned.
A standard warning message would be easy to filter from a logging system and create an alert from to raise visibility.
The goal is simply to raise visibility that an update is available, this prevents feature breaking and improves security. The upgrade process is entirely on the user.
Extended functionality Options:
- Verify if there is an update available for Envoy
- Validate version comparability between Contour and Envoy
- Provide additional log levels where information such as release notes or links can be logged as well
@michmike feels strongly that users test and qualify each release before deploying it so the notion of automatically upgrading seems antithetical.
However, if folks want to do this they can use the :latest tag we maintain,
I'm not making any suggestion that upgrades should be done automatically. Just that providing a notice of a new release can improve security, especially due to the difficulty back porting security fixes without breaking functionality.
I think there are two issues at play here, one is our support policy which states that when we make a new release, any other release is now unsupported. There is a second issue overplayed onto that that some of those releases don't just mean you're unsupported, but potentially exposed to a known vulnerability.
We do know from the k8s slack and issues that our users are not keeping up with our release cadence; there seems to be a 1:1 correlation with bugs reported and users still using 0.15 or older.
The question for me is; are we doing everything possible to notify users who care (some don't, and that's just the way it is) that there is a new contour release of any kind? Something like https://github.com/projectcontour/contour/issues/1796 maybe.
This is something I've been thinking about for a while. We allow (or at least have no way to prevent) users to bring their own envoy, but we don't know whether the envoy they provide is likely to work. Addressing compatibility could use the same mechanism that we use to address security versioning.
I'm not surprised that users are not keeping pace with the release cadence. But that's a whole different topic.
A mailing list is a good idea, for security specific issues you could leverage the security advisories feature in GitHub.
@SDBrett envoy makes the version available in each DiscoveryRequest in the Node message.
It should be straight-forward for Contour to track the supported Envoy versions and at least log when it serves responses to an unsupported Envoy version.
@SDBrett envoy makes the version available in each DiscoveryRequest in the Node message.
hotdamn! when was that added?
On 6 Dec 2019, at 10:51 am, Dave Cheney [email protected] wrote:
@SDBrett envoy makes the version available in each DiscoveryRequest in the Node message.
hotdamn! when was that added?
Not sure, a while ago I think. The Node message will have the extensions added (I think in 1.13), so we can use that to ensure extensions that we need are present.