Ingress¶
Ingress is the term used for a native Kubernetes resource that details the external routes into a cluster. Ingress may provide load balancing, TLS termination, intelligent routing and API Gateway functionality.
cert-manager integrates with Ingress objects to fulfill their role in securing your Kubernetes clusters. TLS Protect For Kubernetes, which provides first-class support for Ingress objects, includes an enterprise-hardened version of cert-manager and capabilities to support machine identities in the enterprise.
Introduction¶
Kubernetes is a platform for building platforms which helps companies modernize with speed and agility. It has a reduced set of opinions about how business demands are fulfilled. This creates technological voids which the Kuberenetes community strives to fill. One such area is Ingress Controllers, for which the community has provided many options.
Design Pattern: Ingress
The principal concern of any ingress controller is to accept traffic from outside a given network space and intelligently pass that traffic on to an internally defined resource. This design pattern focuses on the use case of securely leveraging machine identities for use via ingress controllers. It highlights the need for automation to ensure that once your solution is deployed it stays there, proactively securing workloads long into the future.
Before you begin, it's important to understand the "what" and "why" of Ingress.
What is it?¶
Ingress is a native Kubernetes construct. Objects of this type represent lines of communication from outside a cluster (which could mean the internet) to workloads running inside this cluster. Ingress objects bring network intelligence to multi-purpose proxy servers in the form of routing rules. Without the ability to span this divide Kubernetes would be isolated from the outside world and limited to running non-interactive workloads such as batch jobs.
Whilst Ingress is native to Kubernetes, Ingress Controllers are not. An Ingress object can exist, but without an associated controller to respond, it will remain dormant - somewhat like a car without a driver. Selecting a suitable Ingress Controller is a choice each cluster intends for you to make.
Why is it necessary?¶
In addition to routing rules, Ingress Controllers also provide enhanced security which, given the importance of machine identities, should be your primary concern.
The internet was originally envisioned as a medium for sharing information, however the modern world demands that information should be much better protected. To meet these demands we have seen the steady rise of HTTPS to the point where modern browsers baulk at the use of plain old HTTP so Transport Layer Security (TLS), which enables HTTPS, is now a mandatory requirement. Henceforth you need to enforce the security of your data in transit. Doing so with an Ingress Controller moves TLS termination closer to your workloads thereby helping to prevent misuse and compromise.
Organizations use machine identities to provide end-to-end security of data sent between running processes with the TLS cryptographic protocol. The use of X.509 certificates and HTTPS are the most common manifestation of this.
Those machine identities are sometimes installed at the application endpoint - as a layer of configuration inside your container images. Cloud native principles such as 12 factor dependencies may convince you this is the right choice. It's certainly convenient but this approach has a major flaw in that machine identities eventually expire so they must not be treated as static dependencies of your workloads.
This matters because when active machine identities expire or become unavailable, outages happen.
Outages
Workloads can become unavailable for many reasons and any such event can be described as an outage.
When you choose to secure your workloads, you introduce an additional failure point, specifically the machine identity itself. This is because machine identities are designed to expire after some predefined duration. When machine identities expire they stop working and the workloads they protect become unavailable. A likely outcome of failing to mitigate against outages is negative impact to brand reputation and lost revenue.
Automation using the Machine Identity Management Control Plane is a key defense against outages.
There are further limitations that stem from the use of containers with pre-baked security measures but the example above represents one that can be effectively tackled through the use of an Ingress.
FAQs¶
Before you proceed there may be a few initial questions that need addressing, for example:
"What problem will you solve?"
TLS Protect For Kubernetes users need machine identities that are trusted not just between workloads located on a single cluster using mTLS but also between public-facing workloads and other external clients such as end-user browsers.
"What will the outcome be?"
Users of your public-facing solution can stop outages caused by expiring machine identities. This builds customer trust and loyalty.
"What will you need to deliver?"
You solution will be in the form of Kubernetes controllers and CRDs. Your images will be sourced from a public container registry and installation will be achieved via a Helm chart.
"How will your solution be used?"
Automation via your Ingress controller will be initiated through the use of routes encoded within native Kubernetes Ingress objects. There may be a requirement for supplementary CRDs to configure your controller.
"What about authentication and authorization?"
Whilst it is not a requirement for your solution to handle authentication and authorization, there are Ingress controllers out there which do. If you choose this to provide this, we recommend you integrate with existing OpenID Connect (OIDC) identity providers such as Okta and Ping Identity.
"Why will you want to certify your solution?"
Hop over to our certification section for TLS Protect For Kubernetes to find out more
If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.