Skip to main content

HTTP Ingress

HTTP Ingress Overview​

CloudFlow HTTP Ingress is implemented by an enhanced Kubernetes Ingress Controller that is built upon the open source Nginx Ingress. CloudFlow's enhancements give application developers special capabilities such as IP blocking, handling of SSL certificates, maintenance pages, and HTTP request metadata enhancement with geo IP properties of the end user.

CloudFlow HTTP Ingress has has the following responsibilities:

  • Performing the TLS handshake for HTTPS connections
  • Request enrichment
  • Routing HTTP requests to your applications and services
  • Implementing the HTTP/2 protocol
  • Request correlation

This ingress controller supports TCP port 80 for HTTP and 443 for HTTPS.

The ingress will route traffic to your applications and services based on the host header over HTTP/1.1 regardless of the incoming protocol.

Activating HTTP Ingress​

HTTP Ingress is enabled by declaring in your environment a single Kubernetes service that you name ingress-upstream. Specify the type of Service as ClusterIP. Note that Service resources of type NodePort and LoadBalancer services are not accepted. Note that the standard Kubernetes Ingress resource is not leveraged nor recognized by the Platform.

Check our guide on this topic.

How It Works​

Use of CloudFlow HTTP Ingress causes a deployment of small, special ingress pods that will be charged to your account. There are 2 pods in the deployment with horizontal pod autoscaling turned on. This deployment is charged to your account like any other application containers. You will not be able to see the containers using kubectl.

TLS metadata​

CloudFlow HTTP Ingress performs the TLS handshake with the client on behalf of your application. Some details of this TLS handshake are then relayed to your application by adding HTTP headers to the request.

An x-forwarded-proto header with a value of either http or https is added to indicate if the client used HTTP (i.e. no TLS) or HTTPS to connect. For HTTPS requests, the following headers will also be present.

  • section-io-tls-protocol - the TLS protocol version negotiated with the client. Examples include TLSv1.2 and TLSv1.3.
  • section-io-tls-cipher - the TLS cipher suite negotiated with the client, in OpenSSL naming convention. Examples include ECDHE-RSA-AES128-GCM-SHA256 and TLS_AES_256_GCM_SHA384. For translations to other cipher suite naming conventions see ciphersuite.info or testssl.sh.

IP geolocation​

For each incoming request, the ingress controller will attempt to resolve the client's connecting IP address to a geographic location. The results of the lookup are then exposed as HTTP request headers. These headers are:

  • section-io-geo-country-code - the ISO 3166-1 alpha-2 country code e.g. US for the United States.
  • section-io-geo-country-name - the country name e.g. United States.
  • section-io-geo-asn - ASN number.
  • section-io-geo-region-code - examples include CA and VA for US IPs or NSW for Australian IPs.
  • section-io-geo-region-name - examples include California and Virginia for US IPs or New South Wales for Australian IPs.
  • section-io-geo-city - examples include New York, Mountain View, Sydney, and Drummoyne.
  • section-io-geo-latlon - the approximate latitude and longitude in the format -33.8696,151.2099.
  • section-io-geo-postal-code - examples include 2047 for Drummoyne, NSW, Australia and 80302 for Boulder, CO, USA.
  • section-io-geo-dma-code - The Nielsen Designated Market Area ID as used by DoubleClick. Only for US IPs.

The ingress controller leverages the open source MaxMind GeoIP2 library for geolocation data.

Client IP Detection​

CloudFlow adds the True-Client-IP HTTP header which is equivalent to the remote_addr value. This request header can be used in a number of ways:

  • Fraud detection
  • Logging client usage
  • Rate limiting

CloudFlow also sets the X-Forwarded-For header if you need to use that, however this header will often be a list of IP addresses depending on how the request has been proxied prior to arriving at CloudFlow and is not always reliable.

Request correlation​

When the ingress controller handles each incoming request, a unique identifier is generated and is added to the request via a section-io-id HTTP request header. You can use this value to trace the request through your application stack.

The format of the section-io-id identifier is subject to change without notice so it should be treated as an opaque string and no meaning should be inferred from its value.