Exploring Ingress V1, Graduating to GA in Kubernetes 1.19
In this article, explore Ingress V1 and see new features, security concerns, and what's next.
Join the DZone community and get the full member experience.Join For Free
After five long years, the Ingress API is finally graduating to general availability in Kubernetes 1.19. Since it was first introduced as a beta feature in 2015, the Ingress API has been heavily adopted by users and spawned a rich ecosystem of Ingress Controllers that implement the API, typically through API Gateway-style traffic routers, such as the recently accepted CNCF incubating project Contour.
The Ingress API is the gateway for external access to services within a cluster, typically through HTTP and HTTPS routes. The resource enables users to define rules to manage traffic routing. To give you a sense of its capabilities, the Ingress API can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL/TLS, and offer name-based virtual hosting.
With the GA of Ingress V1, Kubernetes makes official what was already widely practiced within the Kubernetes community. It also comes with some notable new features:
A new IngressClass resource that specifies how ingresses should be implemented by controllers, with the option to reference a custom resource with additional parameters. This replaces the notorious annotations used by different ingress controllers that were not part of the API specification.
A new pathType field that specifies how Ingress paths should be matched. This field can have the following inputs:
ImplementationSpecific (default): With this path type, matching is up to the controller implementing the IngressClass. Implementations can treat this as a separate pathType or treat it identically to the Prefix or Exact path types.
Exact: Matches the URL path exactly and with case sensitivity.
Prefix: Matches based on a URL path prefix split by a “/” character. Matching is case sensitive and done on a path element by element basis.
Wildcard support in hostnames
Many Ingress providers already supported wildcard hostname matching, where the “*” character matched the domain component of the hostname. For example, *.foo.com would match app1.foo.com. Until now, the spec assumed an exact FQDN match of the host. Hosts can now be precise matches (for example “foo.bar.com”) or a wildcard (for example “*.foo.com”). Precise matches require the HTTP host header to match the host setting. Wildcard matches require the HTTP host header to match the suffix of the wildcard rule.
As with any new component in Kubernetes, users should be mindful of the security ramifications. Ingress in particular is the main access point to your application, making security best practices all the more critical. Here are three basic guidelines to keep in mind:
- Secure ingress connections with SSL/TLS encryption.
- Implement security controls at the API gateway. These security rule configurations should be routinely monitored for vulnerabilities.
- Monitor API gateway logs for anomalies. Envoy has extensions for this, such as ModSecurity, that analyze the traffic of API transactions for aberrations.
When using advanced proxies such as Envoy as your ingress controller, be aware that weaknesses are often found in protocol decoding and protocol transcoding. Adversaries can send malicious traffic that exploits an implementation weakness in the protocol parsing parts, or in the way ingress policies and configurations are handled. Fortunately, there is a solid and well practiced upgrading and patching process to remediate vulnerabilities. Security advisories and patches for Envoy are updated regularly on GitHub.
What’s Next: Service APIs
Ingress V1 may have just officially arrived, but it’s already time to look towards the horizon. With the Ingress V1 GA, Kubernetes is setting the stage for Service APIs. Service APIs will build on Ingress to support new use cases, including egress controls, ultimately offering a similar functionality to Istio and other service meshes, without the complexity. In this sense, Service APIs can be seen as the successor to service mesh.
The goals of Service APIs are threefold. First, they will provide cleaner separation and role-based control for different personas and user groups that consume Ingress together — specifically, the application developers, cluster operators, and infrastructure providers. Each persona will map roughly to a role in the Kubernetes Role-Based Authentication Control (RBAC) system, enabling clear separation of responsibility and access.
Second, Service APIs will build on Ingress V1 to include the more advanced routing and load balancing features already common in today’s service meshes. This will include layer 4 and layer 7 protocols, security features, and perhaps most importantly, infrastructure integrations to ensure portability and make end-to-end workflows simple for users.
Lastly, another goal of the Service APIs is to specify standard methods of extending Ingress specification in a clean, scalable, and understandable way. Setting these standards will provide a path for growth as the APIs gain more adoption. While Service APIs are still in the early stages, you should keep them on your radar, as they will solve a lot of operational bottlenecks associated with service meshes and Ingress.
Opinions expressed by DZone contributors are their own.