Contour continues to add new features to help you better manage ingress operations in a cluster. Our latest feature release, Contour 1.9.0, now includes support for external authorization allowing requests to be validated against an authorization server. Contour now also supports presenting a client certificate for TLS for validation to backend services as well as moves to v1 Custom Resource Definitions (CRDs).
Incoming requests to your ingress resources can now be authorized by utilizing Contour’s new external authorization support. Contour now enables the external authorization network filter in Envoy which calls an external authorization service to check if the incoming request is authorized or not. If the request is deemed unauthorized by the network filter then the connection will be closed.
Support for this new feature relies on a new Custom Resource Definition (CRD) named ExtensionService. This new API describes how Envoy should connect to the external authorization server.
ExtensionServiceCRD: This CRD allows the External Authorization Service created in the previous step to be available so that Contour can configure Envoy with that gRPC endpoint.
Here’s a quick video demonstration walking through the setup and configuration of External Authorization with Contour.
If you’d like to follow along with the demo in your own environment, here are the files used:
https://projectcontour.io/examples/authdemo/01-prereq.yaml https://projectcontour.io/examples/authdemo/02-auth-deployment.yaml https://projectcontour.io/examples/authdemo/02-certsjob.yaml https://projectcontour.io/examples/authdemo/03-secret.yaml https://projectcontour.io/examples/authdemo/04-extensionservice.yaml https://projectcontour.io/examples/authdemo/04-samplapp.yaml https://projectcontour.io/examples/authdemo/05-proxy.yaml https://projectcontour.io/examples/authdemo/06-proxy-auth.yaml
CORS uses additional HTTP headers to tell browsers to give a web application running at one origin access to selected resources from a different origin (domain, protocol, or port) from its own.
In this example, cross-domain requests will be allowed for any domain (note the * value):
apiVersion: projectcontour.io/v1 kind: HTTPProxy spec: virtualhost: fqdn: local.projectcontour.io corsPolicy: allowCredentials: true allowOrigin: - "*" # allows any origin allowMethods: - GET - POST - OPTIONS allowHeaders: - authorization - cache-control exposeHeaders: - Content-Length - Content-Range maxAge: "10m" # preflight requests can be cached for 10 minutes. routes: - conditions: - prefix: / services: - name: s1 port: 80
Thanks to @aberasarte and @glerchundi for driving the design and implementation of this new feature!
Contour now supports optionally specifying a Kubernetes secret that Envoy should present to upstream clusters as a client certificate for TLS, so the upstream services can validate that the connection is coming from Envoy.
Thanks to @tsaarni for leading design and implementation of this feature!
Contour now generates v1 custom resource definitions (CRDs) as part of its example YAML.
This enables Contour to take full advantage of the v1 API’s capabilities around validation, defaulting, API documentation via
kubectl explain, and more.
CRDs became generally available in Kubernetes 1.16 over a year ago.
This change bumps Contour’s minimum supported Kubernetes version to 1.16.
We’re immensely grateful for all the community contributions that help make Contour even better! For version 1.9, special thanks go out to the following contributors: