Ingress Gateway

Ingress Gateway

This topic provides reference information for the ingress-gateway configuration entry.

Introduction

You can define an ingress-gateway configuration entry to connect the Consul service mesh to a set of external services. The specification for ingress gateways include a listeners configuration, which exposes the service mesh to the external services. Use camel case (IngressGateway) to declare an ingress gateway configuration entry on Kubernetes.

Refer to the Kubernetes Ingress Gateway documentation for information about configuring ingress gateways on Kubernetes.

For other platforms, see Ingress Gateway.

Requirements

Consul versions 1.8.4+ is required to use the IngressGateway custom resource on Kubernetes.
Consul versions 1.8.0+ is required to use the ingress-gateway custom resource on all other platforms.

Usage

Verify that your datacenter meets the conditions specified in the Requirements.
Create a file containing the configuration entry settings (see Configuration).
Apply the configuration settings using one of the following methods:
- Kubernetes CRD: Refer to the Custom Resource Definitions documentation for details.
- Issue the consul config write command: Refer to the Consul Config Write documentation for details.

Configuration

Use the following syntax to configure an ingress gateway.

HCL

HCL
Kubernetes YAML
JSON

Kind = "ingress-gateway"
Name = "<name for the gateway>"
Listeners = [
  {
    Port = <external service port>
    Protocol = "<protocol used by external service>"
    Services = [
      {
        Name = "<name of external service>"
      }
    ]
  }
]

Kind = "ingress-gateway"
Name = "<name for the gateway>"
Listeners = [
  {
    Port = <external service port>
    Protocol = "<protocol used by external service>"
    Services = [
      {
        Name = "<name of external service>"
      }
    ]
  }
]

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: <name for the gateway>
spec:
  listeners:
    - port: <external service port>
      protocol: <protocol used by external service>
      services:
        - name: <name of external service>

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: <name for the gateway>
spec:
  listeners:
    - port: <external service port>
      protocol: <protocol used by external service>
      services:
        - name: <name of external service>

{
  "Kind": "ingress-gateway",
  "Name": "<name for the gateway>",
  "Listeners": [
    {
      "Port": <external service port>,
      "Protocol": "<protocol used by external service>",
      "Services": [
        {
          "Name": "<name of external service>"
        }
      ]
    }
  ]
}

{
  "Kind": "ingress-gateway",
  "Name": "<name for the gateway>",
  "Listeners": [
    {
      "Port": <external service port>,
      "Protocol": "<protocol used by external service>",
      "Services": [
        {
          "Name": "<name of external service>"
        }
      ]
    }
  ]
}

Refer to the Available Fields section for complete information about all ingress gateway configuration entry options and to the Example Configurations section for example use-cases.

Scope

Configuration entries are global in scope. A configuration entry for a gateway name applies across the default partition of all federated Consul datacenters. If ingress gateways in different Consul datacenters need to route to different sets of services within their datacenter then the ingress gateways must be registered with different names or partitions. See Ingress Gateway for more information.

Wildcard Service Specification

Ingress gateways can optionally target all services within a Consul namespace by specifying a wildcard * as the service name. A wildcard specifier allows for a single listener to route traffic to all available services on the Consul service mesh, differentiating between the services by their host/authority header.

A wildcard specifier provides the following properties for an ingress gateway:

All services with the same protocol as the listener will be routable.
The ingress gateway will route traffic based on the host/authority header, expecting a value matching <service-name>.ingress.*, or if using namespaces, <service-name>.ingress.<namespace>.*. This matches the Consul DNS ingress subdomain.

A wildcard specifier cannot be set on a listener of protocol tcp.

ACLs

Configuration entries may be protected by ACLs.

Reading an ingress-gateway config entry requires service:read on the Name field of the config entry.

Creating, updating, or deleting an ingress-gateway config entry requires operator:write.

Example Configurations

The following examples describe possible use-cases for ingress gateway configuration entries.

TCP listener

The following example sets up a TCP listener on an ingress gateway named us-east-ingress to proxy traffic to the db service. The Consul Enterprise version also posits the gateway listener inside the default namespace and the team-frontend admin partition:

HCL

HCL
Kubernetes YAML
JSON

Kind = "ingress-gateway"
Name = "us-east-ingress"
Listeners = [
  {
    Port     = 3456
    Protocol = "tcp"
    Services = [
      {
        Name = "db"
      }
    ]
  }
]

Kind = "ingress-gateway"
Name = "us-east-ingress"
Listeners = [
  {
    Port     = 3456
    Protocol = "tcp"
    Services = [
      {
        Name = "db"
      }
    ]
  }
]

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: us-east-ingress
spec:
  listeners:
    - port: 3456
      protocol: tcp
      services:
        - name: db

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: us-east-ingress
spec:
  listeners:
    - port: 3456
      protocol: tcp
      services:
        - name: db

{
  "Kind": "ingress-gateway",
  "Name": "us-east-ingress",
  "Listeners": [
    {
      "Port": 3456,
      "Protocol": "tcp",
      "Services": [
        {
          "Name": "db"
        }
      ]
    }
  ]
}

{
  "Kind": "ingress-gateway",
  "Name": "us-east-ingress",
  "Listeners": [
    {
      "Port": 3456,
      "Protocol": "tcp",
      "Services": [
        {
          "Name": "db"
        }
      ]
    }
  ]
}

Wildcard HTTP Listener

In the following example, two listeners are configured on an ingress gateway named us-east-ingress:

The first listener is configured to listen on port 8080 and uses a wildcard (*) to proxy traffic to all services in the datacenter.
The second listener exposes the api and web services on port 4567 at user-provided hosts.
TLS is enabled on every listener.

The Consul Enterprise version implements the following additional configurations:

The ingress gateway is set up in the default namespace and proxies traffic to all services in the frontend namespace.
The api and web services are proxied to team-specific admin partitions:

HCL

HCL
Kubernetes YAML
JSON

Kind = "ingress-gateway"
Name = "us-east-ingress"
TLS {
  Enabled = true
}
Listeners = [
  {
    Port     = 8080
    Protocol = "http"
    Services = [
      {
        Name = "*"
      }
    ]
  },
  {
    Port     = 4567
    Protocol = "http"
    Services = [
      {
        Name  = "api"
        Hosts = ["foo.example.com"]
      },
      {
        Name  = "web"
        Hosts = ["website.example.com"]
      }
    ]
  }
]

Kind = "ingress-gateway"
Name = "us-east-ingress"
TLS {
  Enabled = true
}
Listeners = [
  {
    Port     = 8080
    Protocol = "http"
    Services = [
      {
        Name = "*"
      }
    ]
  },
  {
    Port     = 4567
    Protocol = "http"
    Services = [
      {
        Name  = "api"
        Hosts = ["foo.example.com"]
      },
      {
        Name  = "web"
        Hosts = ["website.example.com"]
      }
    ]
  }
]

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: us-east-ingress
spec:
  tls:
    enabled: true
  listeners:
    - port: 8080
      protocol: http
      services:
        - name: '*'
    - port: 4567
      protocol: http
      services:
        - name: api
          hosts: ['foo.example.com']
        - name: web
          hosts: ['website.example.com']

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: us-east-ingress
spec:
  tls:
    enabled: true
  listeners:
    - port: 8080
      protocol: http
      services:
        - name: '*'
    - port: 4567
      protocol: http
      services:
        - name: api
          hosts: ['foo.example.com']
        - name: web
          hosts: ['website.example.com']

{
  "Kind": "ingress-gateway",
  "Name": "us-east-ingress",
  "TLS": {
    "Enabled": true
  },
  "Listeners": [
    {
      "Port": 8080,
      "Protocol": "http",
      "Services": [
        {
          "Name": "*"
        }
      ]
    },
    {
      "Port": 4567,
      "Protocol": "http",
      "Services": [
        {
          "Name": "api",
          "Hosts": ["foo.example.com"]
        },
        {
          "Name": "web",
          "Hosts": ["website.example.com"]
        }
      ]
    }
  ]
}

{
  "Kind": "ingress-gateway",
  "Name": "us-east-ingress",
  "TLS": {
    "Enabled": true
  },
  "Listeners": [
    {
      "Port": 8080,
      "Protocol": "http",
      "Services": [
        {
          "Name": "*"
        }
      ]
    },
    {
      "Port": 4567,
      "Protocol": "http",
      "Services": [
        {
          "Name": "api",
          "Hosts": ["foo.example.com"]
        },
        {
          "Name": "web",
          "Hosts": ["website.example.com"]
        }
      ]
    }
  ]
}

HTTP listener with Path-based Routing

The following example sets up an HTTP listener on an ingress gateway named us-east-ingress to proxy traffic to a virtual service named api. In the Consul Enterprise version, us-east-ingress is set up in the default namespace and default partition.

In this use-case, internal-only debug headers should be stripped before responding to external clients. Requests to internal services should also be labelled to indicate which gateway they came through.

HCL

HCL
Kubernetes YAML
JSON

Kind = "ingress-gateway"
Name = "us-east-ingress"
Listeners = [
  {
    Port     = 80
    Protocol = "http"
    Services = [
      {
        Name = "api"
        RequestHeaders {
          Add {
            "x-gateway" = "us-east-ingress"
          }
        }
        ResponseHeaders {
          Remove = ["x-debug"]
        }
      }
    ]
  }
]

Kind = "ingress-gateway"
Name = "us-east-ingress"
Listeners = [
  {
    Port     = 80
    Protocol = "http"
    Services = [
      {
        Name = "api"
        RequestHeaders {
          Add {
            "x-gateway" = "us-east-ingress"
          }
        }
        ResponseHeaders {
          Remove = ["x-debug"]
        }
      }
    ]
  }
]

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: us-east-ingress
spec:
  listeners:
    - port: 80
      protocol: http
      services:
        - name: api
          requestHeaders:
            add:
              x-gateway: us-east-ingress
          responseHeaders:
            remove:
              - x-debug

apiVersion: consul.hashicorp.com/v1alpha1
kind: IngressGateway
metadata:
  name: us-east-ingress
spec:
  listeners:
    - port: 80
      protocol: http
      services:
        - name: api
          requestHeaders:
            add:
              x-gateway: us-east-ingress
          responseHeaders:
            remove:
              - x-debug

{
  "Kind": "ingress-gateway",
  "Name": "us-east-ingress",
  "Listeners": [
    {
      "Port": 80,
      "Protocol": "http",
      "Services": [
        {
          "Name": "api",
          "RequestHeaders": {
            "Add": {
              "x-gateway": "us-east-ingress"
            }
          },
          "ResponseHeaders": {
            "Remove": ["x-debug"]
          }
        }
      ]
    }
  ]
}

{
  "Kind": "ingress-gateway",
  "Name": "us-east-ingress",
  "Listeners": [
    {
      "Port": 80,
      "Protocol": "http",
      "Services": [
        {
          "Name": "api",
          "RequestHeaders": {
            "Add": {
              "x-gateway": "us-east-ingress"
            }
          },
          "ResponseHeaders": {
            "Remove": ["x-debug"]
          }
        }
      ]
    }
  ]
}

For this use-case, the api service is not an actual registered service. It exists as a virtual service for L7 configuration only. A service-router (ServiceRouter on Kubernetes) is defined for the virtual service that uses path-based routing to route requests to different backend services:

HCL

HCL
Kubernetes YAML
JSON

Kind = "service-router"
Name = "api"
Routes = [
  {
    Match {
      HTTP {
        PathPrefix = "/billing"
      }
    }
    Destination {
      Service = "billing-api"
    }
  },
  {
    Match {
      HTTP {
        PathPrefix = "/payments"
      }
    }
    Destination {
      Service = "payments-api"
    }
  }
]

Kind = "service-router"
Name = "api"
Routes = [
  {
    Match {
      HTTP {
        PathPrefix = "/billing"
      }
    }
    Destination {
      Service = "billing-api"
    }
  },
  {
    Match {
      HTTP {
        PathPrefix = "/payments"
      }
    }
    Destination {
      Service = "payments-api"
    }
  }
]

apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceRouter
metadata:
  name: api
spec:
  routes:
    - match:
        http:
          pathPrefix: '/billing'
      destination:
        service: billing-api
    - match:
        http:
          pathPrefix: '/payments'
      destination:
        service: payments-api

apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceRouter
metadata:
  name: api
spec:
  routes:
    - match:
        http:
          pathPrefix: '/billing'
      destination:
        service: billing-api
    - match:
        http:
          pathPrefix: '/payments'
      destination:
        service: payments-api

{
  "Kind": "service-router",
  "Name": "api",
  "Routes": [
    {
      "Match": {
        "HTTP": {
          "PathPrefix": "/billing"
        }
      },
      "Destination": {
        "Service": "billing-api"
      }
    },
    {
      "Match": {
        "HTTP": {
          "PathPrefix": "/payments"
        }
      },
      "Destination": {
        "Service": "payments-api"
      }
    }
  ]
}

{
  "Kind": "service-router",
  "Name": "api",
  "Routes": [
    {
      "Match": {
        "HTTP": {
          "PathPrefix": "/billing"
        }
      },
      "Destination": {
        "Service": "billing-api"
      }
    },
    {
      "Match": {
        "HTTP": {
          "PathPrefix": "/payments"
        }
      },
      "Destination": {
        "Service": "payments-api"
      }
    }
  ]
}

Available Fields

You can specify the following parameters to configure ingress gateway configuration entries.

Kind - Must be set to ingress-gateway
Name (string: <required>) - Set to the name of the gateway being configured.
Namespace (string: `default`)

Enterprise

- Specifies the namespace in which the configuration entry will apply. The value must match the namespace in which the gateway is registered. If omitted, the namespace will be inherited from the ns request parameter (refer to the config API endpoint documentation). or will default to the default namespace.
Meta (map<string|string>: nil) - Specifies arbitrary KV metadata pairs. Added in Consul 1.8.4.
Partition (string: "default")

Enterprise

- Specifies the admin partition in which the configuration will apply. The value must match the partition in which the gateway is registered. If omitted, the partition will be inherited from the request (refer to the config API endpoint documentation). See Admin Partitions for additional information.
TLS (TLSConfig: <optional>) - TLS configuration for this gateway.
- Enabled (bool: false) - Set this configuration to true to enable built-in TLS for every listener on the gateway.
  
  If TLS is enabled, then each host defined in each service’s Hosts fields will be added as a DNSSAN to the gateway’s x509 certificate.
- TLSMinVersion (string: "") - Set the default minimum TLS version supported for the gateway’s listeners. One of TLS_AUTO, TLSv1_0, TLSv1_1, TLSv1_2, or TLSv1_3. If unspecified, Envoy v1.22.0 and newer will default to TLS 1.2 as a min version, while older releases of Envoy default to TLS 1.0.
- TLSMaxVersion (string: "") - Set the default maximum TLS version supported for the gateway’s listeners. Must be greater than or equal to TLSMinVersion. One of TLS_AUTO, TLSv1_0, TLSv1_1, TLSv1_2, or TLSv1_3.
- CipherSuites (array<string>: <optional>) - Set the default list of TLS cipher suites for the gateway’s listeners to support when negotiating connections using TLS 1.2 or earlier. If unspecified, Envoy will use a default server cipher list. The list of supported cipher suites can seen in consul/types/tls.go and is dependent on underlying support in Envoy. Future releases of Envoy may remove currently-supported but insecure cipher suites, and future releases of Consul may add new supported cipher suites if any are added to Envoy.
- SDS (SDSConfig: <optional>) - Defines a set of parameters that configures the gateway to load TLS certificates from an external SDS service. See SDS for more details on usage.
  
  SDS properties defined in this field are used as defaults for all listeners on the gateway.
  - ClusterName (string) - Specifies the name of the SDS cluster from which Consul should retrieve certificates. This cluster must be specified in the Gateway’s bootstrap configuration.
  - CertResource (string) - Specifies an SDS resource name. Consul will request the SDS resource name when fetching the certificate from the SDS service. Setting this causes all listeners to be served exclusively over TLS with this certificate unless overridden by listener-specific TLS configuration.
Listeners (array<IngressListener>: <optional>)) - A list of listeners that the ingress gateway should setup, uniquely identified by their port number.
- Port (int: 0) - The port on which the ingress listener should receive traffic. The port will be bound to the IP address that was specified in the -address flag when starting the gateway. Note: The ingress listener port must not conflict with the health check port specified in the -address flag.
- Protocol (string: "tcp") - The protocol associated with the listener. One of tcp, http, http2, or grpc.
- Services (array<IngressService>: <optional>) - A list of services to be exposed via this listener. For tcp listeners, only a single service is allowed. Each service must have a unique name. A namespace is also required for Consul Enterprise.
  - Name (string: "") - The name of the service that should be exposed through this listener. This can be either a service registered in the catalog, or a service defined only by other config entries. If the wildcard specifier, *, is provided, then ALL services will be exposed through the listener. This is not supported for listeners with protocol tcp.
  - Namespace (string: "")
    
    Enterprise
    
    - The namespace from which to resolve the service if different than the existing namespace. The current namespace is used if unspecified.
  - Partition (string: "")
    
    Enterprise
    
    - The admin partition from which to resolve the service if different than the existing partition. The current partition is used if unspecified.
  - Hosts (array<string>: <optional>) - A list of hosts that specify what requests will match this service. This cannot be used with a tcp listener, and cannot be specified alongside a * service name. If not specified, the default domain .ingress.* will be used to match services. Requests must send the correct host to be routed to the defined service.
    
    The wildcard specifier, *, can be used by itself to match all traffic coming to the ingress gateway, if TLS is not enabled. This allows a user to route all traffic to a single service without specifying a host, allowing simpler tests and demos. Otherwise, the wildcard specifier can be used as part of the host to match multiple hosts, but only in the leftmost DNS label. This ensures that all defined hosts are valid DNS records. For example, *.example.com is valid, while example.* and *-suffix.example.com are not.
  - RequestHeaders (HTTPHeaderModifiers: <optional>) - A set of HTTP-specific header modification rules that will be applied to requests routed to this service. This cannot be used with a tcp listener.
  - ResponseHeaders (HTTPHeaderModifiers: <optional>) - A set of HTTP-specific header modification rules that will be applied to responses from this service. This cannot be used with a tcp listener.
  - TLS (ServiceTLSConfig: <optional>) - TLS configuration for this service.
    - SDS (SDSConfig: <optional>) - Defines a set of parameters that configures the SDS source for the certificate for this specific service. At least one custom host must be specified in Hosts. The certificate retrieved from SDS will be served for all requests identifying one of the Hosts values in the TLS Server Name Indication (SNI) header.
      - ClusterName (string) - The SDS cluster name to connect to to retrieve certificates. This cluster must be specified in the Gateway’s bootstrap configuration.
      - CertResource (string) - The SDS resource name to request when fetching the certificate from the SDS service.
- TLS (TLSConfig: <optional>) - TLS configuration for this listener.
  - Enabled (bool: false) - Set this configuration to true to enable built-in TLS for this listener.
    
    If TLS is enabled, then each host defined in each service’s Hosts field will be added as a DNSSAN to the gateway’s x509 certificate. Note that even hosts from other listeners with TLS disabled will be added. TLS can not be disabled for individual listeners if it is enabled on the gateway.
  - TLSMinVersion (string: "") - Set the minimum TLS version supported for this listener. One of TLS_AUTO, TLSv1_0, TLSv1_1, TLSv1_2, or TLSv1_3. If unspecified, Envoy v1.22.0 and newer will default to TLS 1.2 as a min version, while older releases of Envoy default to TLS 1.0.
  - TLSMaxVersion (string: "") - Set the maximum TLS version supported for this listener. Must be greater than or equal to TLSMinVersion. One of TLS_AUTO, TLSv1_0, TLSv1_1, TLSv1_2, or TLSv1_3.
  - CipherSuites (array<string>: <optional>) - Set the list of TLS cipher suites to support when negotiating connections using TLS 1.2 or earlier. If unspecified, Envoy will use a default server cipher list. The list of supported cipher suites can seen in consul/types/tls.go and is dependent on underlying support in Envoy. Future releases of Envoy may remove currently-supported but insecure cipher suites, and future releases of Consul may add new supported cipher suites if any are added to Envoy.
  - SDS (SDSConfig: <optional>) - Defines a set of parameters that configures the listener to load TLS certificates from an external SDS service. See SDS for more details on usage.
    
    SDS properties set here will be used as defaults for all services on this listener.
    - ClusterName (string) - The SDS cluster name to connect to to retrieve certificates. This cluster must be specified in the Gateway’s bootstrap configuration.
    - CertResource (string) - The SDS resource name to request when fetching the certificate from the SDS service.