To enable HTTPS proxying (over TLS or mTLS) between Contour edge proxy and service mesh backends, Contour’s upstream TLS configuration can be used in conjunction with OSM’s IngressBackend configuration to perform peer certificate validation.ĪpiVersion : projectcontour.io/v1 kind : TLSCertificateDelegation metadata : name : osm-ca-secret namespace : osm-system spec : delegations : - secretName : osm-ca-bundle targetNamespaces : - test - apiVersion : projectcontour.io/v1 kind : HTTPProxy metadata : name : basic namespace : test spec : virtualhost : fqdn : routes : - services : - name : foo port : 80 validation : caSecret : osm-system/osm-ca-bundle subjectName : - kind : IngressBackend apiVersion : /v1alpha1 metadata : name : basic namespace : test spec : backends : - name : foo port : number : 80 protocol : https # https implies TLS tls : skipClientCertValidation: false # mTLS (optional, default : false) sources : - kind : Service namespace : osm-system name : osm-contour-envoy - kind : AuthenticatedPrincipal name : HTTPS Ingress with Contour (mTLS and TLS) The IngressBackend configuration will allow access to the foo service on port 80 in the test namespace only if the source originating the traffic is an endpoint of the osm-contour-envoy service in the osm-system namespace.The HTTPProxy configuration will route incoming HTTP traffic originating externally with a Host: header for to a service named foo on port 80 in the test namespace.The above configurations allow external clients to access the foo service in the test namespace as follows: Enable the namespace to be monitored using:ĪpiVersion : projectcontour.io/v1 kind : HTTPProxy metadata : name : basic namespace : test spec : virtualhost : fqdn : routes : - conditions : - prefix : / services : - name : foo port : 80 - kind : IngressBackend apiVersion : /v1alpha1 metadata : name : basic namespace : test spec : backends : - name : foo port : number : 80 protocol : http # http implies no TLS sources : - kind : Service namespace : osm-system name : osm-contour-envoy For OSM to be able to discover the endpoints of a service, the namespace in which the service resides needs to be a monitored namespace. Note that when the Kind for a source in an IngressBackend configuration is set to Service, OSM controller will attempt to discover the endpoints of that service. For https backends, client certificate validation is performed by default and can be disabled by setting skipClientCertValidation: true in the tls field for the backend.

A source with the kind Service is optional for https backends. When the backend protocol is https, the source specified must be an AuthenticatedPrincipal kind which defines the Subject Alternative Name (SAN) encoded in the client’s certificate that the backend will authenticate. When the backend protocol is http, the source specified must be a Service kind whose endpoints will be authorized to connect to the backend. The specification enables configuring how specific backends must authorize ingress traffic depending on the protocol used, HTTP or HTTPS. OSM leverages its IngressBackend API to configure a backend service to accept ingress traffic from trusted sources. OSM’s ingress capability allows cluster administrators and application owners to route traffic from clients external to the service mesh to service mesh backends using a set of rules depending on the mechanism used to perform ingress. Ingress refers to managing external access to services within the cluster, typically HTTP/HTTPS services. Using Ingress to manage external access to services within the cluster Introduction

Ingress regress