Editing Contour Ingress Controller (section)

== HTTPProxy as a replacement for Ingress ==
From the Contour documentation for [https://projectcontour.io/docs/v1.6.1/httpproxy/ HTTPProxy]:

<pre>The Ingress object was added to Kubernetes in version 1.1 to describe properties of a cluster-wide reverse HTTP proxy. Since that time, the Ingress object has not progressed beyond the beta stage, and its stagnation inspired an explosion of annotations to express missing properties of HTTP routing.

The goal of the HTTPProxy (previously IngressRoute) Custom Resource Definition (CRD) is to expand upon the functionality of the Ingress API to allow for a richer user experience as well addressing the limitations of the latter’s use in multi tenent environments.</pre>

From what I have observed, the use of HTTPProxy vs. Ingress results in a simpler manifest with less duplicate information and more flexibility.  There is one challenge, however:

<pre>cert-manager currently does not have a way to interact with HTTPProxy objects in order to respond to the HTTP01 challenge correctly. (See [https://github.com/projectcontour/contour/issues/950 #950] and [https://github.com/projectcontour/contour/issues/951 #951] for details.) ... This means that cert-manager can’t be directly used for generating certificates for HTTPProxy configuration.</pre>

=== Using HTTPProxy ===
The workaround for this problem is to create a dummy Ingress with enough information to pass YAML validation and trigger cert-manager to create a certificate ... but not enough to actually create any routes.  Here are the resulting manifests using the examples as above:

 apiVersion: projectcontour.io/v1
 kind: HTTPProxy
 metadata:
   name: httpbinproxy
 spec:
   virtualhost:
     fqdn: httpbinproxy.davecheney.com
     tls:
       secretName: httpbin
   routes:
   - services:
     - name: httpbin
       port: 8080

This object will be marked as Invalid by Contour, since the TLS secret doesn’t exist yet. Once that’s done, create the dummy Ingress object:

 apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   annotations:
     cert-manager.io/cluster-issuer: letsencrypt-prod
     ingress.kubernetes.io/force-ssl-redirect: "true"
     kubernetes.io/tls-acme: "true"
   name: httpbinproxy
   namespace: default
 spec:
   rules:
   - host: httpbinproxy.davecheney.com
     http:
       paths:
       - backend:
           serviceName: httpbin
           servicePort: 8080
   tls:
   - hosts:
     - httpbinproxy.davecheney.com
     secretName: httpbin

Set the hostname as appropriate, and make sure the secret names match.  This seems excessive, as this does nothing more than the example in the Ingress section above ... but it does come in handy when the added capability of a HTTPProxy is needed.

=== Encrypted Upstream Communication ===
While many (most?) upstream services are happy to just handle unencrypted communications, some require the use of TLS (HTTPS).  This is a problem since the Ingress terminates the SSL/TLS session and the resulting communication with the upstream service is unencrypted.  

This is a simple example of the power of the HTTPProxy, and the flexibility it provides over an Ingress.  The HTTPProxy allows the specification of what protocol (specifically, which encryption protocol) is used for communicating with the upstream service.  Here is the above example HTTPProxy communicating with the upstream service on port 443 using HTTPS (TLS):

 apiVersion: projectcontour.io/v1
 kind: HTTPProxy
 metadata:
   name: httpbinproxy
 spec:
   virtualhost:
     fqdn: httpbinproxy.davecheney.com
     tls:
       secretName: httpbin
   routes:
   - services:
     - name: httpbin
       port: 443
       protocol: tls

This will instruct Contour to terminate the incoming SSL/TLS with the specified hostname's certificate, and then initiate a new TLS connection to the upstream process specified by the service provided.