We are delighted to present version v1.20.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

A big thank you to everyone who contributed to the release.

• Changes
• Docs Changes
• Deprecations/Removals
• Installing/Upgrading
• Compatible Kubernetes Versions

Changes

• Fixed a bug where upstream TLS SNI (HTTProxy.spec.routes.requestHeadersPolicy Host key) and protocol fields might not take effect when e.g. two HTTPProxies were otherwise equal but differed only on those fields. (#4350, @tsaarni)
• Update github.com/prometheus/client_golang to v1.11.1 to address CVE-2022-21698. (#4361, @tsaarni)
• Updates Envoy to v1.21.1. See the Envoy changelog for details. (#4365, @skriss)

Docs Changes

• Added documentation for HTTPProxy request redirection. (#4367, @sunjayBhatia)

Installing and Upgrading

For a fresh install of Contour, consult the getting started documentation.

To upgrade an existing Contour installation, please consult the upgrade documentation.

Compatible Kubernetes Versions

Contour v1.20.1 is tested against Kubernetes 1.21 through 1.23.

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

We are delighted to present version v1.20.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

A big thank you to everyone who contributed to the release.

Major Changes

Gateway API v1alpha2 support

Contour now exclusively supports Gateway API v1alpha2, the latest available version.
This version of Gateway API has a number of breaking changes, which are detailed in the Gateway API changelog.
Contour currently supports a single GatewayClass and associated Gateway, and HTTPRoutes and TLSRoutes that attach to the Gateway. TCPRoute and UDPRoute are not supported.
For a list of other functionality that remains to be implemented, see Contour's area/gateway-api label.

As part of this change, support for Gateway API v1alpha1 has been dropped, and any v1alpha1 resources will not be automatically converted to v1alpha2 resources because the API has moved to a different API group (from networking.x-k8s.io to gateway.networking.k8s.io).

(#4047, @skriss)

xDS management connection between Contour and Envoy set to TLSv1.3

The minimum accepted TLS version for Contour xDS server is changed from TLSv1.2 to TLSv1.3.
Previously in Contour 1.19, the maximum accepted TLS version for Envoy xDS client was increased to TLSv1.3 which allows it to connect to Contour xDS server using TLSv1.3.

If upgrading from a version prior to Contour 1.19, the old Envoys will be unable to connect to new Contour until also Envoys are upgraded.
Until that, old Envoys are unable to receive new configuration data.

For further information, see Contour architecture and xDS API in Envoy documentation.

(#4065, @tsaarni)

Minor Changes

Metrics over HTTPS

Both Envoy and Contour metrics can now be served over HTTPS.
Server can alternatively also require client to present certificate which is validated against configured CA certificate.
This feature makes it possible to limit the visibility of metrics to authorized clients.

(#3707, @tsaarni)

Performance improvement for processing configuration

The performance of Contour's configuration processing has been made more efficient, particularly for clusters with large numbers (i.e. >1k) of HTTPProxies and/or Ingresses.
This means that there should be less of a delay between creating/updating an HTTPProxy/Ingress in Kubernetes, and having it reflected in Envoy's configuration.

(#4099, @skriss)

Allow retry policy, num retries to be zero

The field, NumRetries (e.g. count), in the RetryPolicy allows for a zero to be
specified, however Contour's internal logic would see that as "undefined"
and set it back to the Envoy default of 1. This would never allow the value of
zero to be set. Users can set the value to be -1 which will represent disabling
the retry count. If not specified or set to zero, then the Envoy default value
of 1 is used.

(#4117, @stevesloka)

Gateway API: implement PathPrefix matching

Contour now implements Gateway API v1alpha2's "path prefix" matching for HTTPRoutes.
This is now the only native form of prefix matching supported by Gateway API, and is a change from v1alpha1.
Path prefix matching means that the prefix specified in an HTTPRoute rule must match entire segments of a request's path in order to match it, rather than just be a string prefix.
For example, the prefix /foo would match a request for the path /foo/bar but not /foobar.
For more information, see the Gateway API documentation.

(#4119, @skriss)

Add Envoy Deployment Example

The examples now include a way to deploy Envoy as a Deployment vs a Daemonset.
This can assist in allowing Envoy to drain connections cleanly when the Kubernetes cluster size is scaled down.

(#4126, @stevesloka)

Default status on HTTPProxy resources

When a new HTTPProxy is created, if Contour isn't yet running or
functioning properly, then no status is set on the resource.
Defaults of "NotReconciled/Waiting for controller" are now applied
to any new object until an instance of Contour accepts the
object and updates the status.

(#4133, @stevesloka)

Gateway API: support ReferencePolicy

Contour now supports the ReferencePolicy CRD in Gateway API v1alpha2.
ReferencePolicy enables certain cross-namespace references to be allowed in Gateway API.
The primary use case is to enable routes (e.g. HTTPRoutes, TLSRoutes) to reference backend Services in different namespaces.
When Contour processes a route that references a service in a different namespace, it will check for a ReferencePolicy that applies to the route and service, and if one exists, it will allow the reference.

(#4138, @skriss)

Source IP hash based load balancing

Contour users can now configure their load balancing policies on HTTPProxy resources to hash the source IP of a client to ensure consistent routing to a backend service instance. Using this feature combined with header value hashing can implement advanced request routing and session affinity. Note that if you are using a load balancer to front your Envoy deployment, you will need to ensure it preserves client source IP addresses to ensure this feature is effective.

See this page for more details on this feature.

(#4141, @sunjayBhatia)

Gateway API: set Gateway Listener status fields

Contour now sets the .status.listeners.supportedKinds and .status.listeners.attachedRoutes fields on Gateways for Gateway API.
The first describes the list of route groups/kinds that the listener supports, and the second captures the total number of routes that are successfully attached to the listener.

(#4160, @skriss)

TLS Certificate validation updates

Contour now allows non-server certificates that do not have a CN or SAN set, which mostly fixes
#2372 and #3889.

TLS documentation has been updated to make the rules for Secrets holding TLS information clearer.

Those rules are:

For certificates that identify a server, they must:

• be kubernetes.io/tls type
• contain tls.crt, and tls.key keys with the server certificate and key respectively.
• have the first certificate in the tls.crt bundle have a CN or SAN field set.

They may:

• have the tls.crt key contain a certificate chain, as long as the first certificate in the chain is the server certificate.
• add a ca.crt key that contains a Certificate Authority (CA) certificate or certificates.

Certificates in the certificate chain that are not server certificates do not need to have a CN or SAN.

For CA secrets, they must:

• be Opaque type
• contain only a ca.crt key, not tls.crt or tls.key

The ca.crt key may contain one or more CA certificates, that do not need to have a CN or SAN.

(#4165, @youngnick)

HTTPProxy TCPProxy service weights are now applied

Previously, Contour did not apply any service weights defined in an HTTPProxy's TCPProxy, and all services were equally weighted.
Now, if those weights are defined, they are applied so traffic is weighted appropriately across the services.
Note that if no TCPProxy service weights are defined, traffic continues to be equally spread across all services.

(#4169, @skriss)

Leader Election Configuration

contour serve leader election configuration via config file has been deprecated.
The preferred way to configure leader election parameters is now via command line flags.
See here for more detail on the new leader election flags.

Note: If you are using the v1alpha1 ContourConfiguration CRD, leader election configuration has been removed from that CRD as well.
Leader election configuration is not something that will be dynamically configurable once Contour implements configuration reloading via that CRD.

(#4171, @sunjayBhatia)

Set Gateway listener conditions

Contour now sets various Gateway listener conditions as it processes them, including the "Ready", "Detached", and "ResolvedRefs" condition types, to provide more visibility to the user as to whether their listeners are defined correctly or not.

(#4186, @skriss)

HTTP Request Redirect Policy

HTTPProxy.Route now has a HTTPRequestRedirectPolicy which allows for routes to specify a RequestRedirectPolicy.
This policy will allow a redirect to be configured for a specific set of Conditions within a single route.
The policy can be configured with a Hostname, StatusCode, Scheme, and Port.

Additionally, Services on a Route are now optional when a request redirect is defined.

(#4201, @stevesloka)

Transition to controller-runtime managed leader election

Contour now utilizes controller-runtime Manager based leader election and coordination of subroutines.
With this change, Contour is also transitioning away from using a ConfigMap for leader election.
In this release, Contour now uses a combination of ConfigMap and Lease object.
A future release will remove usage of the ConfigMap resource for leader election.

This change should be a no-op for most users, however be sure to re-apply the relevant parts of your deployment for RBAC to ensure Contour has access to Lease and Event objects (this would be the ClusterRole in the provided example YAML).

(#4202, @sunjayBhatia)

HTTPRedirectPolicy allows for Path rewriting

Adds a Path & Prefix field to the HTTPProxy.Spec.Route.RequestRedirectPolicy which allows
for redirects to also specify the path or prefix to redirect to. When specified, an
HTTP 302 response will be sent to the requestor with the new path or prefix specified.

Note: Only one of path or prefix can be specified on a single route.

Sample HTTPProxy:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: redirect-path
spec:
  virtualhost:
    fqdn: redirect.projectcontour.io
  routes:
    - conditions:
        - prefix: /blog
      services:
        - name: blogservice
          port: 80
      requestRedirectPolicy:
        path: /blog/site

Request:

$ curl -i http://redirect.projectcontour.io/blog                                                                                                

HTTP/2 302 
location: http://redirect.projectcontour.io/blog/site
vary: Accept-Encoding
date: Wed, 15 Dec 2021 20:42:04 GMT
server: envoy

(#4244, @stevesloka)

Other Changes

• Sets conditions of "Accepted: false" and "ValidBackendRefs: false" on TLSRoutes when all backend refs have a weight of 0 explicitly set. (#4027, @skriss)
• Fix panic in Contour startup when using --root-namespaces flag (#4110, @sunjayBhatia)
• Gateway API: adds support for HTTP method matching in HTTPRoute rules. See the Gateway API documentation for more information. (#4120, @skriss)
• Gateway API: adds support for the "RequestRedirect" HTTPRoute filter type at the rule level. (#4123, @skriss)
• Update to using Envoy bootstrap Admin access_log field instead of deprecated access_log_path (deprecated in Envoy v1.18.0) (#4142, @sunjayBhatia)
• Update to using Envoy XFF Original IP Detection extension instead of HTTPConnectionManager xff_num_trusted_hops field (deprecated in Envoy v1.19.0) (#4142, @sunjayBhatia)
• HTTPProxy resources now support wildcard fqdn's in the form *.projectcontour.io. (#4145, @stevesloka)
• Adds a new field, withRequestBody, within HTTPProxy's authorizationServer to allow client request body to be sent to the external authorization server. See External Authorization Configuration Overview for more information. (#4148, @abhide)
• Timeout for upstream network connection timeout increased from 250 msec to 2 seconds. (#4151, @tsaarni)
• Fix accidental negation of disableAllowChunkedLength configuration flag. (#4152, @sunjayBhatia)
• Replaces the use of the dynamic Kubernetes client with the controller-runtime client. (#4153, @skriss)
• Gateway API: Contour no longer sets up RBAC for TCPRoutes and UDPRoutes or watches them, since they are not supported. (#4166, @skriss)
• Very long (~100 characters) Ingress path prefix matches should now no longer be rejected by Envoy. See this issue for context. (#4197, @sunjayBhatia)
• Removes spec.ttlSecondsAfterFinished from certgen job in versioned releases, as immediately deleting it upon completion will not be useful for most consumers. (#4200, @lrewega)
• Gateway API: set an HTTPRoute condition of "ValidMatches: false" when a path match does not start with '/' or contains consecutive '/' characters. (#4209, @skriss)
• Gateway API: allow Gateways to reference TLS certificates in other namespaces when an applicable ReferencePolicy is defined. See the Gateway API documentation for more information. (#4212, @skriss)
• Gateway API: "core" is no longer allowed as a magic string to reference the core Kubernetes API group. Instead, the empty string should be used to align with the Gateway API spec. (#4219, @skriss)
• Updates Go version to 1.17.5, which includes fixes for CVE-2021-44716 and CVE-2021-44717. See the Go release announcement for more information. (#4232, @skriss)
• Gateway API: set Gateway's .status.addresses based on the IP or hostname of the Envoy service (if it's a LoadBalancer service). (#4236, @skriss)
• Contour has been updated to run on Kubernetes 1.23. It is now tested against Kubernetes 1.21 through 1.23. (#4261, @skriss)
• Update Gateway API to v0.4.1 (#4268, @skriss)
• Adds a new Ingress annotation, projectcontour.io/tls-cert-namespace, to allow TLS Certificate Delegation to be used with Ingress v1. (#4271, @pablo-ruth)
• Bump Envoy to v1.21.0. See release notes. (#4273, @sunjayBhatia)
• Fixes bug in certgen error handling when writing certs to kubernetes. (#4281, @sunjayBhatia)
• Fixes a bug where the global headers policy ApplyToIngress field was being ignored, causing Ingresses never to have the global headers policy applied. (#4287, @skriss)

Docs Changes

• Pare down docs versions available in site dropdown. (#4020, @sunjayBhatia)
• Updates the cert-manager guide to use the latest versions of Contour and cert-manager as well as Ingress v1 resources. (#4115, @skriss)
• The Contour deprecation policy for Alpha APIs has been updated to be explicitly more lenient in regards to behavior changes and field removal. A new API version is not strictly required when making such changes. (#4173, @sunjayBhatia)
• Updates the Gateway API guide to use Gateway API v1alpha2. (#4262, @skriss)
• Adds documentation for header manipulation when using Ingress v1 resources. (#4279, @sunjayBhatia)
• Revise the "Getting Started" guide for clarity and to cover more types of clusters and ways of installing Contour. (#4288, @skriss)

Deprecation and Removal Notices

Contour v1.20.0 is the last release that will be pushed to Docker Hub.
We've been pushing images to GitHub Container Registry (GHCR) for several releases now, and all example YAML manifests have been updated to use the GHCR image.
If you haven't yet updated your own install, now is the time to switch to ghcr.io/projectcontour/contour:v1.20.0.
Past images will be left in Docker Hub indefinitely.

Installing and Upgrading

For a fresh install of Contour, consult the getting started documentation.

To upgrade an existing Contour installation, please consult the upgrade documentation.

Compatible Kubernetes Versions

Contour v1.20.0 is tested against Kubernetes 1.21 through 1.23.

Community Thanks!

We’re immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors:

• @abhide
• @lrewega
• @pablo-ruth

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

We are delighted to present the first beta for Contour v1.20.0, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Please note that this is pre-release software, and as such we do not recommend installing it in production environments.
Feedback and bug reports are welcome!

Major Changes

Gateway API v1alpha2 support

Contour now exclusively supports Gateway API v1alpha2, the latest available version.
This version of Gateway API has a number of breaking changes, which are detailed in the Gateway API changelog.
Contour currently supports a single GatewayClass and associated Gateway, and HTTPRoutes and TLSRoutes that attach to the Gateway. TCPRoute and UDPRoute are not supported.
For a list of other functionality that remains to be implemented, see Contour's area/gateway-api label.

As part of this change, support for Gateway API v1alpha1 has been dropped, and any v1alpha1 resources will not be automatically converted to v1alpha2 resources because the API has moved to a different API group (from networking.x-k8s.io to gateway.networking.k8s.io).

To get started, see the Contour & Gateway API (v1alpha2) guide.

(#4047, @skriss)

xDS management connection between Contour and Envoy set to TLSv1.3

The minimum accepted TLS version for Contour xDS server is changed from TLSv1.2 to TLSv1.3.
Previously in Contour 1.19, the maximum accepted TLS version for Envoy xDS client was increased to TLSv1.3 which allows it to connect to Contour xDS server using TLSv1.3.

If upgrading from a version prior to Contour 1.19, the old Envoys will be unable to connect to new Contour until also Envoys are upgraded.
Until that, old Envoys are unable to receive new configuration data.

For further information, see Contour architecture and xDS API in Envoy documentation.

(#4065, @tsaarni)

Minor Changes

Metrics over HTTPS

Both Envoy and Contour metrics can now be served over HTTPS.
Server can alternatively also require client to present certificate which is validated against configured CA certificate.
This feature makes it possible to limit the visibility of metrics to authorized clients.

(#3707, @tsaarni)

Performance improvement for processing configuration

The performance of Contour's configuration processing has been made more efficient, particularly for clusters with large numbers (i.e. >1k) of HTTPProxies and/or Ingresses.
This means that there should be less of a delay between creating/updating an HTTPProxy/Ingress in Kubernetes, and having it reflected in Envoy's configuration.

(#4099, @skriss)

Allow retry policy, num retries to be zero

The field, NumRetries (e.g. count), in the RetryPolicy allows for a zero to be
specified, however Contour's internal logic would see that as "undefined"
and set it back to the Envoy default of 1. This would never allow the value of
zero to be set. Users can set the value to be -1 which will represent disabling
the retry count. If not specified or set to zero, then the Envoy default value
of 1 is used.

(#4117, @stevesloka)

Gateway API: implement PathPrefix matching

Contour now implements Gateway API v1alpha2's "path prefix" matching for HTTPRoutes.
This is now the only native form of prefix matching supported by Gateway API, and is a change from v1alpha1.
Path prefix matching means that the prefix specified in an HTTPRoute rule must match entire segments of a request's path in order to match it, rather than just be a string prefix.
For example, the prefix /foo would match a request for the path /foo/bar but not /foobar.
For more information, see the Gateway API documentation.

(#4119, @skriss)

Gateway API: support ReferencePolicy

Contour now supports the ReferencePolicy CRD in Gateway API v1alpha2.
ReferencePolicy enables certain cross-namespace references to be allowed in Gateway API.
The primary use case is to enable routes (e.g. HTTPRoutes, TLSRoutes) to reference backend Services in different namespaces.
When Contour processes a route that references a service in a different namespace, it will check for a ReferencePolicy that applies to the route and service, and if one exists, it will allow the reference.

(#4138, @skriss)

Gateway API: set Gateway Listener status fields

Contour now sets the .status.listeners.supportedKinds and .status.listeners.attachedRoutes fields on Gateways for Gateway API.
The first describes the list of route groups/kinds that the listener supports, and the second captures the total number of routes that are successfully attached to the listener.

(#4160, @skriss)

Set Gateway listener conditions

Contour now sets various Gateway listener conditions as it processes them, including the "Ready", "Detached", and "ResolvedRefs" condition types, to provide more visibility to the user as to whether their listeners are defined correctly or not.

(#4186, @skriss)

Default status on HTTPProxy resources

When a new HTTPProxy is created, if Contour isn't yet running or
functioning properly, then no status is set on the resource.
Defaults of "NotReconciled/Waiting for controller" are now applied
to any new object until an instance of Contour accepts the
object and updates the status.

(#4133, @stevesloka)

Source IP hash based load balancing

Contour users can now configure their load balancing policies on HTTPProxy resources to hash the source IP of a client to ensure consistent routing to a backend service instance. Using this feature combined with header value hashing can implement advanced request routing and session affinity. Note that if you are using a load balancer to front your Envoy deployment, you will need to ensure it preserves client source IP addresses to ensure this feature is effective.

See this page for more details on this feature.

(#4141, @sunjayBhatia)

TLS Certificate validation updates

Contour now allows non-server certificates that do not have a CN or SAN set, which mostly fixes
#2372 and #3889.

TLS documentation has been updated to make the rules for Secrets holding TLS information clearer.

Those rules are:

For certificates that identify a server, they must:

• be kubernetes.io/tls type
• contain tls.crt, and tls.key keys with the server certificate and key respectively.
• have the first certificate in the tls.crt bundle have a CN or SAN field set.

They may:

• have the tls.crt key contain a certificate chain, as long as the first certificate in the chain is the server certificate.
• add a ca.crt key that contains a Certificate Authority (CA) certificate or certificates.

Certificates in the certificate chain that are not server certificates do not need to have a CN or SAN.

For CA secrets, they must:

• be Opaque type
• contain only a ca.crt key, not tls.crt or tls.key

The ca.crt key may contain one or more CA certificates, that do not need to have a CN or SAN.

(#4165, @youngnick)

HTTPProxy TCPProxy service weights are now applied

Previously, Contour did not apply any service weights defined in an HTTPProxy's TCPProxy, and all services were equally weighted.
Now, if those weights are defined, they are applied so traffic is weighted appropriately across the services.
Note that if no TCPProxy service weights are defined, traffic continues to be equally spread across all services.

(#4169, @skriss)

Leader Election Configuration

contour serve leader election configuration via config file has been deprecated.
The preferred way to configure leader election parameters is now via command line flags.
See here for more detail on the new leader election flags.

Note: If you are using the v1alpha1 ContourConfiguration CRD, leader election configuration has been removed from that CRD as well.
Leader election configuration is not something that will be dynamically configurable once Contour implements configuration reloading via that CRD.

(#4171, @sunjayBhatia)

Transition to controller-runtime managed leader election

Contour now utilizes controller-runtime Manager based leader election and coordination of subroutines.
With this change, Contour is also transitioning away from using a ConfigMap for leader election.
In this release, Contour now uses a combination of ConfigMap and Lease object.
A future release will remove usage of the ConfigMap resource for leader election.

This change should be a no-op for most users, however be sure to re-apply the relevant parts of your deployment for RBAC to ensure Contour has access to Lease and Event objects (this would be the ClusterRole in the provided example YAML).

(#4202, @sunjayBhatia)

HTTP Request Redirect Policy

HTTPProxy.Route now has a HTTPRequestRedirectPolicy which allows for routes to specify a RequestRedirectPolicy.
This policy will allow a redirect to be configured for a specific set of Conditions within a single route.
The policy can be configured with a Hostname, StatusCode, Scheme, and Port.

Additionally, Services on a Route are now optional when a request redirect is defined.

(#4201, @stevesloka)

Other Changes

• Sets conditions of "Accepted: false" and "ValidBackendRefs: false" on TLSRoutes when all backend refs have a weight of 0 explicitly set. (#4027, @skriss)
• Fix panic in Contour startup when using --root-namespaces flag (#4110, @sunjayBhatia)
• Gateway API: adds support for HTTP method matching in HTTPRoute rules. See the Gateway API documentation for more information. (#4120, @skriss)
• Gateway API: adds support for the "RequestRedirect" HTTPRoute filter type at the rule level. (#4123, @skriss)
• Update to using Envoy bootstrap Admin access_log field instead of deprecated access_log_path (deprecated in Envoy v1.18.0) (#4142, @sunjayBhatia)
• Update to using Envoy XFF Original IP Detection extension instead of HTTPConnectionManager xff_num_trusted_hops field (deprecated in Envoy v1.19.0) (#4142, @sunjayBhatia)
• HTTPProxy resources now support wildcard fqdn's in the form *.projectcontour.io. (#4145, @stevesloka)
• Timeout for upstream network connection timeout increased from 250 msec to 2 seconds. (#4151, @tsaarni)
• Fix accidental negation of disableAllowChunkedLength configuration flag. (#4152, @sunjayBhatia)
• Replaces the use of the dynamic Kubernetes client with the controller-runtime client. (#4153, @skriss)
• Gateway API: Contour no longer sets up RBAC for TCPRoutes and UDPRoutes or watches them, since they are not supported. (#4166, @skriss)
• Very long (~100 characters) Ingress path prefix matches should now no longer be rejected by Envoy. See this issue for context. (#4197, @sunjayBhatia)
• Removes spec.ttlSecondsAfterFinished from certgen job in versioned releases, as immediately deleting it upon completion will not be useful for most consumers. (#4200, @lrewega)
• Gateway API: set an HTTPRoute condition of "ValidMatches: false" when a path match does not start with '/' or contains consecutive '/' characters. (#4209, @skriss)
• Gateway API: allow Gateways to reference TLS certificates in other namespaces when an applicable ReferencePolicy is defined. See the Gateway API documentation for more information. (#4212, @skriss)

Docs Changes

• Pare down docs versions available in site dropdown. (#4020, @sunjayBhatia)
• Updates the cert-manager guide to use the latest versions of Contour and cert-manager as well as Ingress v1 resources. (#4115, @skriss)
• Adds a Gateway API v1alpha2 guide. (#4122, @skriss)
• The Contour deprecation policy for Alpha APIs has been updated to be explicitly more lenient in regards to behavior changes and field removal. A new API version is not strictly required when making such changes. (#4173, @sunjayBhatia)

Installing

The simplest way to install v1.20.0-beta.1 is to apply one of the example configurations:

With Gateway API:

kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.20.0-beta.1/examples/render/contour-gateway.yaml

Without Gateway API:

kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.20.0-beta.1/examples/render/contour.yaml

Compatible Kubernetes Versions

Contour v1.20.0-beta.1 is tested against Kubernetes 1.20 through 1.22

Documentation

Documentation corresponding to v1.20.0-beta.1 can be found at https://projectcontour.io/docs/main/.

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

We are delighted to present version 1.18.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

This is a backport release to 1.18, bringing the below change in.

Updates

Allow retry policy, num retries to be disabled

The field, NumRetries (e.g. count), in the RetryPolicy allows for a zero to be
specified, however Contour's internal logic would see that as "undefined"
and set it back to the Envoy default of 1. This would never allow the value of
zero to be set. Users can set the value to be -1 which will represent disabling
the retry count. If not specified or set to zero, then the Envoy default value
of 1 is used.

We are delighted to present version 1.19.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Updates

Allow retry policy, num retries to be disabled

The field, NumRetries (e.g. count), in the RetryPolicy allows for a zero to be
specified, however Contour's internal logic would see that as "undefined"
and set it back to the Envoy default of 1. This would never allow the value of
zero to be set. Users can set the value to be -1 which will represent disabling
the retry count. If not specified or set to zero, then the Envoy default value
of 1 is used.

Panic with --root-namespaces flag

Fix panic in Contour startup when using --root-namespaces flag

We are delighted to present version 1.19.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Updates

Use unix socket for Envoy admin webpage (#3934)

Moves the Envoy admin interface to use a unix socket by creating a new Envoy listener to expose read only information from Envoy admin page over port 9001 (by default).
This change helps to mitigate a Contour CVE which could possibly allow for an ExternalName service to serve the Envoy Admin interface when not desired.

Also updates shutdown-manager to use new unix socket to begin Envoy draining procedure.

Ingress header policies (#4018)

Enable setting headers on all routes on ingress objects by allowing headers to be configured in the Contour config and applied to PolicyConfig.applyToIngress: true.

Example:

    policy:
      # Default headers to set on all requests
      request-headers:
        set:
          X-Envoy-Hostname: %HOSTNAME%
        applyToIngress: true

Push images to GHCR and Docker Hub in parallel (#4006)

Starts pushing container images to GHCR in addition to Docker Hub.
Images will be pushed to both registries for a period of time, until the Docker Hub push is removed.

Going forward, the examples & quickstart will utilize the GHCR registry with images like: ghcr.io/projectcontour/contour.

Run Envoy as non-root (#4084)

Envoy no longer need to run as root but runs as nobody.

Make shutdown-ready file path configurable (#4084)

The shutdown-ready file path is now configurable, to allow user to optionally set a path that is writable by setting the --ready-file flag on the shutdown-manager.

HTTPProxy Per-Route and Service Cookie Rewriting

Contour now enables users to customize attributes on HTTP Set-Cookie response headers.
Application specific cookies and cookies generated by Contour's "cookie" load balancing strategy can be rewritten either per HTTPProxy Route or Service.
Users can choose to rewrite the Path, Domain, Secure, and SameSite attributes of the Set-Cookie header currently.
These attributes may be things an application may not be able to accurately set, without prior knowledge of how the application is deployed.
For example, if Contour is in use to rewrite the path or hostname of a request before it reaches an application backend, the application may not be able to accurately set the Path and Domain attributes in a Set-Cookie response header.
This feature can be used to apply security settings to ensure browsers treat generated cookies appropriately.
The SameSite and Secure attributes are currently not set by Envoy when it generates the X-Contour-Session-Affinity, but with this feature, users can customize this cookie further.
Future iterations of this feature may provide cookie rewriting configuration directly as part of the cookie load balancing strategy configuration.

Some more documentation and example configuration can be found here.
Also see Contour's CRD API reference for more details.

ContourConfiguration CRD in Alpha

Contour uses a set of flags on the contour serve command as well as a configuration file represented as in a Kubernetes Configmap for further configuration of Contour & Envoy.
It has been difficult to manage the contents of that file (e.g. yaml in a configmap) along with having no way of properly validating that conifguration, so Contour has introduced
a new ContourConfiguration CRD which refactors the current config file along with any missing flags into a new object.
This new config is in an Alpha state while we verify the format of the configuration file along with its validation.

Contour will continue to support the current configuration file for some time, but looking ahead to the roadamp, ContourConfiguration will be the new way to configure Contour.

Additional details around the design of this change can be read in the design doc: https://github.com/projectcontour/contour/blob/main/design/configuration-crd.md

New Changelog process

Contour now requires:

• All PRs be labelled with a release-note/ label, where category is one of major, minor, small, docs, infra, or not-required.
• A changelog file to be created in changelogs/unreleased for each PR, unless the category is not-required. The filename must be PR#-githubID-category, where githubID is that of the person opening the PR, and the category matches the label category.

Gateway API

Support TLSRoute weighted ForwardTos (#3938)

Add support for weighted ForwardTos in TLSRoute rules.
Per spec, weights default to 1 if unspecified, and weights of 0 mean no traffic is forwarded to the backend.

Site

Alt attribute to images (#3917)

Adds alt tags for better web accessibility.

Thanks @johnnycase for contributing this!

Website notice feature (#3955)

Adds site formatting for projectcontour.io to have new "warning", "note", "info", and "tip" notices.

Thanks @gary-tai for contributing this!

Misc

Update security process docs post advisory (#3945)

Updates the security process should a new security advisory be discovered with Contour.

Add threat model and security posture documentation (#4011)

Adds a Security document outlining Contour's threat model and how to report security issues.

Updates for Kubernetes 1.22 (#3953)

Updates Go modules, KinD images, and kubectl version to support Kubernetes 1.22.

Code of Conduct (#4032)

Updates the Code of Conduct to use the CNCF template.

Thanks @mzrithm for contributing this!

Upgrading

Please consult the upgrade documentation.

Compatible Kubernetes Versions

Contour v1.19.0 is tested against Kubernetes 1.20 through 1.22

Community Thanks!

We’re immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors:

• @gary-tai
• @senthilnathan
• @mzrithm
• @johnnycase

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

We are delighted to present version 1.18.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Performance Fix for Processing Config

#4061 Fixes a performance issue in Contour's config processing. This issue primarily impacted users with very large numbers of HTTPProxies/Ingresses/Services, who were seeing Contour take up to a minute or two to process additional configuration. With this fix, processing times should be significantly improved for users with many resources. See #4058 and #4061 for additional information.

Upgrading

Instructions for upgrading to Contour 1.18.2 can be found here.

We are delighted to present version 1.18.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Envoy Admin Interface Changes to Mitigate CVE-2021-32783

As an additional mitigation for CVE-2021-32783, PR #3934 has been backported to this release. Previously an ExternalName service with an address of localhost and port matching the Envoy admin interface listener port could expose admin endpoints that would allow an attacker to shut down Envoy remotely. Contour's bootstrap command now configures Envoy to listen on a Unix domain socket to ensure an ExternalName service cannot expose the "writable" endpoints of the admin interface. For backwards compatibility Contour now configures an additional Envoy listener to expose endpoints useful for debugging. This listener does not expose any endpoints that can be used to modify data, set Envoy healthcheck status, or shut down Envoy. See this documentation page for some more detail.

Note: While this fix does mitigate some aspects of CVE-2021-32783, ExternalName service usage is still discouraged as they can still be used to expose services across namespaces.

If you have been using the Contour example YAMLs to deploy Contour and Envoy, no changes are required except to deploy the updated YAMLs for release 1.18.1.

If you are managing your Envoy DaemonSet using another method, be sure to inspect the updated YAML for required changes. An additional volume is required and it must be mounted in the shutdown-manager and envoy containers to ensure both have access to the Unix domain socket Envoy is now configured to listen on.

Envoy Updated to 1.19.1

Upgrades the default Envoy version to 1.19.1 for security and bug fixes. See the Envoy 1.19.1 changelogs for more details.

We are delighted to present version 1.17.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Envoy Admin Interface Changes to Mitigate CVE-2021-32783

As an additional mitigation for CVE-2021-32783, PR #3934 has been backported to this release. Previously an ExternalName service with an address of localhost and port matching the Envoy admin interface listener port could expose admin endpoints that would allow an attacker to shut down Envoy remotely. Contour's bootstrap command now configures Envoy to listen on a Unix domain socket to ensure an ExternalName service cannot expose the "writable" endpoints of the admin interface. For backwards compatibility Contour now configures an additional Envoy listener to expose endpoints useful for debugging. This listener does not expose any endpoints that can be used to modify data, set Envoy healthcheck status, or shut down Envoy. See this documentation page for some more detail.

Note: While this fix does mitigate some aspects of CVE-2021-32783, ExternalName service usage is still discouraged as they can still be used to expose services across namespaces.

If you have been using the Contour example YAMLs to deploy Contour and Envoy, no changes are required except to deploy the updated YAMLs for release 1.17.2.

If you are managing your Envoy DaemonSet using another method, be sure to inspect the updated YAML for required changes. An additional volume is required and it must be mounted in the shutdown-manager and envoy containers to ensure both have access to the Unix domain socket Envoy is now configured to listen on.

Envoy Updated to 1.18.4

Upgrades the default Envoy version to 1.18.4 for security and bug fixes. See the Envoy 1.18.4 changelogs for more details.

We are delighted to present version 1.16.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Envoy Admin Interface Changes to Mitigate CVE-2021-32783

As an additional mitigation for CVE-2021-32783, PR #3934 has been backported to this release. Previously an ExternalName service with an address of localhost and port matching the Envoy admin interface listener port could expose admin endpoints that would allow an attacker to shut down Envoy remotely. Contour's bootstrap command now configures Envoy to listen on a Unix domain socket to ensure an ExternalName service cannot expose the "writable" endpoints of the admin interface. For backwards compatibility Contour now configures an additional Envoy listener to expose endpoints useful for debugging. This listener does not expose any endpoints that can be used to modify data, set Envoy healthcheck status, or shut down Envoy. See this documentation page for some more detail.

Note: While this fix does mitigate some aspects of CVE-2021-32783, ExternalName service usage is still discouraged as they can still be used to expose services across namespaces.

If you have been using the Contour example YAMLs to deploy Contour and Envoy, no changes are required except to deploy the updated YAMLs for release 1.16.1.

If you are managing your Envoy DaemonSet using another method, be sure to inspect the updated YAML for required changes. An additional volume is required and it must be mounted in the shutdown-manager and envoy containers to ensure both have access to the Unix domain socket Envoy is now configured to listen on.

Envoy Updated to 1.18.4

Upgrades the default Envoy version to 1.18.4 for security and bug fixes. See the Envoy 1.18.4 changelogs for more details.

We are delighted to present version 1.15.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Envoy Admin Interface Changes to Mitigate CVE-2021-32783

As an additional mitigation for CVE-2021-32783, PR #3934 has been backported to this release. Previously an ExternalName service with an address of localhost and port matching the Envoy admin interface listener port could expose admin endpoints that would allow an attacker to shut down Envoy remotely. Contour's bootstrap command now configures Envoy to listen on a Unix domain socket to ensure an ExternalName service cannot expose the "writable" endpoints of the admin interface. For backwards compatibility Contour now configures an additional Envoy listener to expose endpoints useful for debugging. This listener does not expose any endpoints that can be used to modify data, set Envoy healthcheck status, or shut down Envoy. See this documentation page for some more detail.

Note: While this fix does mitigate some aspects of CVE-2021-32783, ExternalName service usage is still discouraged as they can still be used to expose services across namespaces.

If you have been using the Contour example YAMLs to deploy Contour and Envoy, no changes are required except to deploy the updated YAMLs for release 1.15.2.

If you are managing your Envoy DaemonSet using another method, be sure to inspect the updated YAML for required changes. An additional volume is required and it must be mounted in the shutdown-manager and envoy containers to ensure both have access to the Unix domain socket Envoy is now configured to listen on.

Envoy Updated to 1.18.4

Upgrades the default Envoy version to 1.18.4 for security and bug fixes. See the Envoy 1.18.4 changelogs for more details.

We are delighted to present version 1.14.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Envoy Admin Interface Changes to Mitigate CVE-2021-32783

As an additional mitigation for CVE-2021-32783, PR #3934 has been backported to this release. Previously an ExternalName service with an address of localhost and port matching the Envoy admin interface listener port could expose admin endpoints that would allow an attacker to shut down Envoy remotely. Contour's bootstrap command now configures Envoy to listen on a Unix domain socket to ensure an ExternalName service cannot expose the "writable" endpoints of the admin interface. For backwards compatibility Contour now configures an additional Envoy listener to expose endpoints useful for debugging. This listener does not expose any endpoints that can be used to modify data, set Envoy healthcheck status, or shut down Envoy. See this documentation page for some more detail.

Note: While this fix does mitigate some aspects of CVE-2021-32783, ExternalName service usage is still discouraged as they can still be used to expose services across namespaces.

If you have been using the Contour example YAMLs to deploy Contour and Envoy, no changes are required except to deploy the updated YAMLs for release 1.14.2.

If you are managing your Envoy DaemonSet using another method, be sure to inspect the updated YAML for required changes. An additional volume is required and it must be mounted in the shutdown-manager and envoy containers to ensure both have access to the Unix domain socket Envoy is now configured to listen on.

Envoy Updated to 1.17.4

Upgrades the default Envoy version to 1.17.4 for security and bug fixes. See the Envoy 1.17.4 changelogs for more details.

We are delighted to present version v1.18.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

A big thank you to everyone who contributed to the release.

Major Changes

ExternalName Services changes

Kubernetes Services of type ExternalName will now not be processed by Contour without active action by Contour's operator. This prevents a vulnerability where an attacker with access to create Service objects inside a cluster running Contour could force Contour's Envoy to expose its own admin interface to the internet with a Service with an ExternalName of localhost or similar.

With access to Envoy's admin page, an attacker can force Envoy to restart or drain connections (which will cause Kubernetes to restart it eventually). The attacker can also see the names and metadata of TLS Secrets, but not their contents.

This version includes two main changes:

• ExternalName Service processing is now disabled by default, and must be enabled.
• Even when processing is enabled, obvious attempts to expose localhost will be prevented. This is quite a porous control, and should not be relied on as your sole means of mitigation.

In short, we recommend migration away from ExternalName Services as soon as you can.

I currently use ExternalName Services, what do I need to do?

If you are currently using ExternalName Services with your Contour installation, it's still recommended that you update to this version.

However, as part of updating, you will need to add the enableExternalNameService: "true" directive to your Contour configuration file. This is not recommended for general use, because of the concerns above, but we have but some mitigations in place to stop obvious misuse of ExternalName Services if you must have them enabled.

Note that because of the cross-namespace control issues documented at kubernetes/kubernetes#103675, you should definitely consider if you can move away from using ExternalName Services in any production clusters.

The ability to enable ExternalName Services for Contour is provided to help with migration, it is not recommended for use in production clusters.

Gateway API Improvements

GatewayClass and Gateway deletion

Contour 1.18.0 ensures when a GatewayClass or Gateway is deleted, it is removed from Contour's cache and DAG.
Routes programmed in Envoy are properly removed as well.

Relevant PRs:

• #3923 : internal/controller: fix Gateway/GatewayClass deletion bug

GatewayClass with non-nil Spec.ParametersRef handling

Previously Contour would not admit GatewayClasses with a non-nil Spec.ParametersRef.
This release ensures these GatewayClasses are still reconciled (Spec.ParametersRef is ignored).

Relevant PRs:

• #3876 : internal/validation: allow GatewayClass.Spec.ParametersRef to be specified

Secrets used for upstream TLS validation can be delegated across namespaces

Previously Contour would not allow a secret referenced in HTTPProxy upstream validation to reside in a different namespace from the HTTPProxy object itself.
This release includes a change to allow users to utilize TLS certificate delegation to relax this restriction.
Users will now be able to create a TLSCertificateDelegation object to allow the owner of the CA certificate secret to delegate, for the purposes of referencing the CA certificate in a different namespace, permission to Contour to read the Secret object from another namespace.
You may want to take advantage of this feature to consolidate secrets in a management namespace and delegate their usage to an app namespace containing the relevant HTTPProxy.

Thanks to @shashankram for implementing this feature!

Relevant PRs:

• #3894 : internal/dag: allow delegation of upstream validation CACertificate

IngressClassName field added to HTTPProxy

To ensure forwards-compatibility with k8s standards around Ingress, Contour has added the Spec.IngressClassName field, to mimic the similar Ingress object field.
HTTPProxy objects could previously be filtered via annotation but now will also be filtered using the same rules as Ingress objects, taking into account the Spec field.

Relevant PRs:

• #3902 : HTTPProxy: add Spec.IngressClassName

Access Logging Enhancements

The Envoy text access log format string can now be customized via the accesslog-format-string field in the Contour config file.
In addition, the REQ_WITHOUT_QUERY access logging extension is enabled in Contour, which allows logging of a request path with any query string stripped.
Note that using this command operator extension requires Envoy 1.19.0.
See this documentation page for more details.

Thanks to @tsaarni for contributing this feature and documentation!

Relevant PRs:

• #3694 : internal/envoy: configurable access log format
• #3849 : site: Added versioned access logging document
• #3921 : site: update access logging links

Envoy Updated to 1.19.0

Contour 1.18.0 is compatible with Envoy 1.19.0. For more information, see the Contour compatibility matrix.

Relevant PRs:

• #3887 : update Envoy to 1.19.0

Documentation Working Group Contributions

Thanks to @gary-tai for helping clean up the project site.

Relevant PRs:

• #3913 : Kindly running post - fix broken links
• #3919 : Blog updates - fix 2 blog posts for broken image links

Upgrading

Please consult the upgrade documentation.

Compatible Kubernetes Versions

Contour v1.18.0 is tested against Kubernetes 1.19 through 1.21

Community Thanks!

We’re immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors:

• @tsaarni
• @shashankram
• @gary-tai

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

Today we present version v1.17.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

This is a security release, which fixes the advisory at GHSA-5ph6-qq5x-7jwc.

Thanks to @josh-ferrell for the initial report.

ExternalName Services changes

Kubernetes Services of type ExternalName will now not be processed by Contour without active action by Contour's operator. This prevents a vulnerability where an attacker with access to create Service objects inside a cluster running Contour could force Contour's Envoy to expose its own admin interface to the internet with a Service with an ExternalName of localhost or similar.

With access to Envoy's admin page, an attacker can force Envoy to restart or drain connections (which will cause Kubernetes to restart it eventually). The attacker can also see the names and metadata of TLS Secrets, but not their contents.

This version includes two main changes:

• ExternalName Service processing is now disabled by default, and must be enabled.
• Even when processing is enabled, obvious attempts to expose localhost will be prevented. This is quite a porous control, and should not be relied on as your sole means of mitigation.

In short, we recommend migration away from ExternalName Services as soon as you can.

I currently use ExternalName Services, what do I need to do?

If you are currently using ExternalName Services with your Contour installation, it's still recommended that you update to this version.

However, as part of updating, you will need to add the enableExternalNameService: "true" directive to your Contour configuration file. This is not recommended for general use, because of the concerns above, but we have but some mitigations in place to stop obvious misuse of ExternalName Services if you must have them enabled.

Note that because of the cross-namespace control issues documented at kubernetes/kubernetes#103675, you should definitely consider if you can move away from using ExternalName Services in any production clusters.

The ability to enable ExternalName Services for Contour is provided to help with migration, it is not recommended for use in production clusters.

We are delighted to present version 1.17.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

A big thank you to everyone who contributed to the release.

Major changes

Tech Writing Working Group

Jonas Rosland (@jonasrosland) and Orlin Vasilev (@OrlinVasilev ) have started a Tech Writing Working Group for Contour. Please see our announcement blog for all the details, and if tech writing is your jam, please get involved!

We've also started to see our first documentation changes coming out of this initiative, which is amazing! Thanks very much to our new contributors!

Please see the following PRs for the blog post and relevant changes:
#3791 : Technical Docs Work group block and guide
#3821 : Fix:contour: error: expected argument for flag --kubernetes-debug, try --help
#3830 : Add troubleshooting page

Ignoring irrelevant Endpoint updates

As reported in #3782, previously to this release, endpoint changes for services not relevant to Contour would cause a no-op configuration push to Envoy. This caused a lot of churn in busy clusters.

This issue has been fixed by #3852.

Thanks to @Zsolt-LazarZsolt for logging the issue.

Gateway API

Reconciling Gateways

In the Gateway API, Gateways refer to a GatewayClass, and controllers decide which Gateways to reconcile by first deciding which GatewayClass(es) they are responsible for.
This is specified using the spec.controller field in the GatewayClass.
It's expected that controllers look for a specific value in that field and only reconcile Gateways that reference GatewayClasses that match.

In this release, Contour has changed the method by which it selects which Gateway is the one to reconcile. It now follows the spec with respect to looking up a GatewayClass and finding the first created Gateway in that GatewayClass to be the Gateway it will watch for config when using the Gateway API.

This is accomplished by specifying the value to look for inside the GatewayClass spec.controller field using the controllerName field inside the gateway stanza in the config file.

This means that the name and namespace parameters in the gateway stanza inside the Contour config file are now deprecated and will be removed in Contour v1.18.0. Please migrate to setting the gateway.controllerName field in the Contour config file instead. Note that although they are deprecated, they are still required. This will be fixed in v1.18.0.

TLSRoute termination mode now supported

Contour now supports the Gateway API TLSRoute object's terminate mode, which terminates TLS at the Gateway.

Please see:
#3801 : internal/dag: Implement TLSRoute mode:terminate

Testing changes

The team has been working away at improving our testing framework and CI infrastructure.

As well as a number of other changes, our CI now runs Contour out-of-cluster to enable testing multiple configurations - this will allow us to test more combinations of config and objects, and increase our overall test coverage.

For the details, please see:
#3803 : test/e2e: tests use Contour running locally
#3848 : test/e2e: check for nil condition in http requestUntil
#3844 : Controller Runtime test suite improvements (on top of #3773)
#3842 : Update test scripts README for new e2e format
#3798 : site: Fixup codespell errors
#3776 : Use up to date go in e2e/upgrade CI jobs
#3774 : test/scripts: install Gateway API CRDs from examples/gateway

Deprecations

Config file: gateway.name and gateway.namespace

As described in the "Reconciling Gateways" section, these config file parameters are deprecated and will be removed in Contour v1.18.0.

Please see:
#3827 : pkg/config: Mark Gateway.Name & Gateway.Namespace as deprecated

make gencerts

Contour currently has a make gencerts available in the local Makefile for creating certificates for securing Contour to Envoy traffic.
This has been superseded by the contour certgen command, which can output to local files in a variety of formats, or directly to Kubernetes Secrets.
This part of the Makefile is therefore deprecated and will be removed in Contour 1.18.

Please see:
#3750 : Refactor Makefile and update local dev options

Other changes

#3811 : Fixes Rendered Gateway Example
#3841 : Bump gomega package to 1.13.0
#3836 : Bump golang to 1.16.5
#3834 : Bump protobuf and fix lint issues
#3833 : Bump ginkgo to 1.16.4
#3809 : Fix references to kuard-dag.png
#3793 : test/e2e: Pull deployment manifest unmarshal/update into framework
#3796 : Update compatibility docs and release cutting notes
#3795 : Fix label sync, update labels, add new decision issue type
#3794 : site: replace latest_release_tag_name with latest_version
#3788 : site: use a single param for latest version
#3785 : site: bulk replacement of Jekyll templates
#3783 : site: Fixup RateLimiting Guide & some other links
#3781 : site: Fixup the upgrade guide
#3780 : site: Fixup configuration page for move to Hugo
#3778 : site: Fix links on deploy-options pages
#3777 : site: Fix link to HTTPProxy fundamentals for Annotations page

Upgrading

Please consult the upgrade documentation.

Compatible Kubernetes Versions

Contour v1.17.0 is tested against Kubernetes 1.19 through 1.21.

Community Thanks!

We’re immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors:

• @johnnycase
• @Patil2099
• @Zsolt-LazarZsolt

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

We are delighted to present version 1.16.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

A big thank you to everyone who contributed to the release.

Major Changes

Gateway API

Added Initial Support for TLSRoute

PR https://github.com/projectcontour/contour/pull/3627 added support for TLSRoute to enable Passthrough TCP Proxying to pods via SNI. See https://github.com/projectcontour/contour/issues/3440 for additional information on TLSRoute feature requirements.

GatewayClass Support

PR https://github.com/projectcontour/contour/pull/3659 added GatewayClass support through the gateway.controllerName configuration parameter. The gateway.namespace and gateway.name parameters are required when setting gateway.controllerName. When the cluster contains Gateway API CRDs and this parameter is set, Contour will reconcile GatewayClass resources with the spec.controller field that matches gateway.controllerName. ControllerName should take the form of projectcontour.io/<namespace>/contour, where <namespace> is the namespace that Contour runs in.

CA is No Longer Ignored when Downstream "Skip Verify" is True

With PR https://github.com/projectcontour/contour/pull/3661, Contour will no longer ignore a certificate under the following conditions:

• If no CA is set and "skip verify" is true, client certs are not required by Envoy.
• If CA set and "skip verify" is true, client certs are required by Envoy.
• CA is still required if "skip verify" is false.
• caCert is now optional since skipClientCertValidation can be true. PR https://github.com/projectcontour/contour/pull/3658 added an omitempty JSON tag to omit the caCert field when serializing to JSON and it hasn't been specified.

Website Update

PR https://github.com/projectcontour/contour/pull/3704 revamps the Contour website based on Hugo. Check out the fresh new look and tell us what you think.

Deprecation & Removal Notices

• PR https://github.com/projectcontour/contour/pull/3642 removed the experimental-service-apis flag has been removed. The gateway.name & gateway.namespace in the Contour configuration file should be used for configuring Gateway API (formerly Service APIs).
• PR https://github.com/projectcontour/contour/pull/3645 removed support for Ingress v1beta1. Ingress v1 resources should be used with Contour.

Upgrading

Please consult the upgrade documentation.

Community Thanks!

We’re immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors:

• @geoffcline
• @pandeykartikey
• @pyaillet

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

We are delighted to present version 1.15.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Upgrades the default Envoy version to 1.18.3 for security and bug fixes. See the Envoy 1.18.3 changelogs for more details.

• CVE-2021-29492 (CVSS score 8.3, High): Envoy versions 1.18.2 and earlier does not decode escaped slash sequences %2F and %5C in HTTP URL paths. A remote attacker may craft a path with escaped slashes, e.g. /something%2F..%2Fadmin, to bypass access control, e.g. a block on /admin. A backend server could then decode slash sequences and normalize path which would provide an attacker access beyond the scope provided for by the access control policy.

We are delighted to present version 1.15.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

A big thank you to everyone who contributed to the release.

Major Changes

Gateway API

Contour v1.15.0 supports GatewayAPI v0.3.0 which was released on 04/29/21. Not all of the features in GatewayAPI are fully supported yet in Contour, however, v1.15.0 adds some new features outlined below:

• Filter on Gateway.Listener.Protocol for supported types (#3612): Filters on the protocols that Contour supports.
• Fix processing of httproutes validation (#3598): Fixes a bug where additional HTTPRoutes would not get processed after the first one was processed.
• Add support for TLS on Gateway (#3472): For HTTPRoutes, TLS can be specified on the Gateway.Listener which terminates TLS at Envoy before proxying to any Kubernetes service.
• Upgrade to gateway-api v0.3.0 (#3623): Contour supports the latest version of gateway-api, v0.3.0.
• Process HTTPRoute.Spec.Gateways (#3618): Implement support for HTTPRoutes.Spec.Gateways to allow an HTTPRoute to define how it binds to a Gateway via "All", "SameNamespace", or "FromList".
• Update HTTPRoute status to only allow a single Type (#3600): Updates the HTTPRoute status logic to only allow a single condition "Type". Previously multiple Types would be allowed in Contour v1.14.
• Update RBAC permissions for gateway-api types to allow for Status to be updated (#3570): Note this will require re-applying the Contour RBAC permissions for status to work correctly.

If you're interested in following the GatewayAPI implementation progress in Contour, issue #2287 is the Epic issue which outlines all the features that have been implemented as well as those that are still not yet complete.

IPv6

Contour 1.15 improves its IPv6 support. Bootstrap clusters with IP addresses are now configured as STATIC in Envoy, to fix an issue where IPv6 addresses were not properly parsed (#3572). Also, IPv6 addresses are now consistently accepted as flag values (#3579). Thanks @sunjayBhatia for fixing these issues!

Global rate limiting

Contour 1.15 adds support for the HeaderValueMatch rate limiting descriptor type, which allows for generation of descriptor entries based on complex matching against header values. As part of this, "notpresent" is now a supported header match operator (#3599 #3602). For more information, see the global rate limiting documentation. Thanks to @skriss for implementing this feature.

Ingress wildcard hosts

As part of fully supporting the Ingress v1 API, Contour now supports Ingresses with wildcard hosts. The first DNS label in a host name can be a wildcard, e.g. *.projectcontour.io, which will match foo.projectcontour.io but not foo.bar.projectcontour.io. You can read more about the API spec in the Kubernetes Ingress documentation. This was implemented by @sunjayBhatia in #3381.

Skipping client cert verification for downstream TLS

HTTPProxy now supports skipping verification when client certificates are requested for downstream TLS, via the spec.virtualhost.tls.clientValidation.skipClientCertValidation field. This is not enabled by default. This can be used in conjunction with an external authorization server as Envoy will still require client certificates to be supplied, and will pass them along to the external authorization server for verification (#3611). Thanks to @sunjayBhatia for implementing this feature!

Customizable admin port for shutdown-manager

Contour's shutdown-manager now supports a customizable admin port, via the --admin-port flag (#3501). Thanks to @alessandroargentieri for implementing this!

Envoy 1.18.2

Contour 1.15 is compatible with Envoy 1.18.2 (#3589). For more information, see the Contour compatibility matrix.

Kubernetes 1.21

Contour 1.15 is supported on Kubernetes 1.21 (#3581 #3609). For more information, see the Contour compatibility matrix.

Bugs Fixed

• Fixed a bug where default header policies were not being applied unless an HTTPProxy also had headers being set (#3550). Thanks @mattatcha for finding and fixing!

Upgrading

Please consult the upgrade documentation.

Community Thanks!

We’re immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors:

• @nak3
• @mattatcha
• @alessandroargentieri

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.

We are delighted to present version 1.14.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

Fixes

Upgrades the default Envoy version to 1.17.2 for security and bug fixes. See the Envoy 1.17.2 changelogs for more details.

• CVE-2021-28682 (CVSS score 7.5, High): Envoy through 1.17.1, 1.16.2, 1.15.3, and 1.14.6 contains a remotely exploitable integer overflow via a very large grpc-timeout value causes undefined behavior.
• CVE-2021-28683 (CVSS score 7.5, High): Envoy through 1.17.1 and 1.16.2 contains a remotely exploitable crash in TLS when an unknown TLS alert code is received.
• CVE-2021-29258 (CVSS score 7.5, High): Envoy through 1.17.1, 1.16.2, 1.15.3, and 1.14.6 contains a remotely exploitable crash in Envoy's HTTP2 Metadata, when an empty METADATA map is sent.

We are delighted to present version 1.14.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.

A big thank you to everyone who contributed to the release.

Major Changes

Global Rate Limiting

This release adds a new boolean configuration that defines whether to include the X-RateLimit headers X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset (as defined by this IETF Internet-Draft), on responses to clients when the Rate Limit Service is consulted for a request.

Related Issues and PRs: #3431 #3457

This release also fixes a bug whereby applying a rateLimitPolicy on an HTTPProxy using a genericKey entry, the key field of the genericKey was ignored and the default value (generic_key) was passed on to the RLS.

Related Issues and PRs: #3443 #3445

Ingress v1 Support

Contour now supports filtering Ingress resources using the IngressClass name in the Ingress spec. Previously, users could only select certain Ingress resources with the now-deprecated annotation. Support for using the annotation to specify an IngressClass name to watch has not been removed. The existing contour serve --ingress-class-name flag can still be used to specify an IngressClass name to use as an Ingress filter. The rules around this flag are as follows:

• If the flag is not passed to contour serve Contour will accept any Ingress resource that specifies the IngressClass name contour in annotation or spec fields or does not specify one at all.
• If the flag is passed to contour serve Contour will only accept Ingress resources that exactly match the specified IngressClass name via annotation or spec field, with the value in the annotation taking precedence

Related Issues and PRs: #2146 #3520

Users can now specify different path matching modes for HTTP requests according to the Ingress v1 spec. Contour supports Exact path matching that will match a request path exactly, Prefix path matching that will match path prefixes, and an ImplementationSpecific path matching type.

Prefix path matches follow the Ingress spec and do not match using a "string prefix" but rather a path segment prefix (e.g. a prefix /foo/bar will match the path /foo/bar/baz but not /foo/barbaz). This is a difference from Contour's existing Ingress support which implemented "string prefix" matching for all path matches. For backwards compatibility the ImplementationSpecific match type retains the existing pre-1.14.0 behavior and will do a "string prefix" match if a plain path is specified or a regex match if a path is specified that contains regex meta-characters. Users who did not specify a path matching type on their Ingress resources should require no intervention as the API server defaults those rules to ImplementationSpecific, however anyone using an explicit Prefix match may have to review their Ingress resources to ensure "segment prefix" matches work for them.

Related Issues and PRs: #2135 #3471

Default Header Policy

Contour can be configured to set or remove HTTP request and response headers by default through parameters in the config file. These defaults will apply to all HTTP requests and responses unless overridden by users in an HTTPProxy.

Related Issues and PRs: #3258 #3270 #3519

Bootstrap Generated SDS Resources Permissions

SDS resources written by the contour bootstrap command are now written with more a permissive mode to ensure Envoy running as a non-root user is able to access them.

Related Issues and PRs: #3264 #3390

Port Stripped from Hostname Sent to Upstreams

HTTP requests with a port in the hostname header are now configured to be stripped by Envoy in internal processing and when forwarded to upstream services.

Related Issues and PRs: #3458

Example Deployment Envoy Service Ports

The Envoy service in the Contour example deployment YAML has been updated to use target ports of 8080 and 8443 (replacing the original ports 80 and 443). Contour will also configure Envoy to now use those ports (its default values) for HTTP and HTTPS listener ports.

Related Issues and PRs: #3393

Deprecation & Removal Notices

• The following Prometheus Gauges have been removed in favor of Gauges added in Contour 1.13.0 with more idiomatic names. Any dashboard and alert queries referring to the old names must be updated to use the new metrics.

  contour_httpproxy_total -> contour_httpproxy
  contour_httpproxy_invalid_total  -> contour_httpproxy_invalid
  contour_httpproxy_orphaned_total  -> contour_httpproxy_orphaned
  contour_httpproxy_valid_total  -> contour_httpproxy_valid
  contour_httpproxy_root_total  -> contour_httpproxy_root
  

Upgrading

Please consult the upgrade documentation.

Community Thanks!

We’re immensely grateful for all the community contributions that help make Contour even better! For version 1.14, special thanks go out to the following contributors:

• @abhide
• @erwbgy
• @furdarius
• @nak3
• @arthurlm
• @prondubuisi

Are you a Contour user? We would love to know!

If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.