Skip to main content

HTTP Ingress

HTTP Ingress Overview

Section HTTP Ingress is implemented by an enhanced Kubernetes Ingress Controller that is built upon the open source Nginx Ingress. Section'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.

Section 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.

Activation of Section HTTP Ingress is what causes traffic data to be visible on Traffic Monitor.

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 Section 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.

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

Section 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

Section 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 Section 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.