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.
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.
Section 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.
x-forwarded-proto header with a value of either
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
section-io-tls-cipher- the TLS cipher suite negotiated with the client, in OpenSSL naming convention. Examples include
TLS_AES_256_GCM_SHA384. For translations to other cipher suite naming conventions see ciphersuite.info or testssl.sh.
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.
USfor the United States.
section-io-geo-country-name- the country name e.g.
section-io-geo-asn- ASN number.
section-io-geo-region-code- examples include
VAfor US IPs or
NSWfor Australian IPs.
section-io-geo-region-name- examples include
Virginiafor US IPs or
New South Walesfor Australian IPs.
section-io-geo-city- examples include
section-io-geo-latlon- the approximate latitude and longitude in the format
section-io-geo-postal-code- examples include
2047for Drummoyne, NSW, Australia and
80302for 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.
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.