Keeping Data Secure

Secure Ingress + TLS TerminationWorking in an increasingly connected world, maintaining the security of users and their data is a challenging problem to solve. As we move into a state where service meshes are becoming a better way to provide availability of services to your users, it’s also more important to ensure that the data is secured from the moment it leaves the user’s device until it is ingressed into your service mesh. In an interconnected world increasingly focused on the security of both users and their data, secure ingress is a fundamentally complex but necessary part of the service mesh architecture.

Today, I’d like to talk about secure ingress, TLS termination and how this all affects users and maintainers of an Istio service mesh. We’ll also touch on some of the pitfalls of setting up TLS termination as well as how Aspen Mesh attempts to simplify the entire process, so your teams are free to focus on providing value to your customers.

 

Security and You: What is Secure Ingress?

So you’ve got your services up and running, sidecars injected, Prometheus churning out stats and Istio working properly in your cluster; you’re ready to start processing user data and adding value. But your security team is leery about that TCP ingress you’ve been using for testing. Gateways and Virtual Services are great, and while passing TLS requirements down to the service has been working, they want a stronger assertion. How can you make sure that all datawhether or not it is secured within the service meshis encrypted with no setup from the services themselves?

Enter secure ingress. By configuring TLS requirements on your Istio Gateway, you can make sure that all information is encrypted, even without TLS on your services. Istio supports TLS certificates in both traditional file mount setups as well as in Kubernetes secrets

 

Configuration Issues (Otherwise Known As: ANOTHER 503 UF UR?!)

You’ve decided that TLS termination is the way to go, sounds amazing! No more needing to worry about services handling TLS requirements, and we can even JWT secure our endpoints! You deploy the gateway, virtual service and authorization policy and once you’ve got your TLS certs deployed, you hit that endpoint and get… A 503 status? Looking at the Istio ingress gateway logs only tells you that there was an upstream connection failure (UF) and the upstream connection reset (UR). What’s going on?

Welcome to layer seven TCP routing and mTLS requirements. By deploying an authorization policy to JWT to secure your ingress endpoints, you may have inadvertently disabled mTLS, causing your sidecars to balk at communicating. Maybe you haven’t even been fully using sidecars for some of the services up until this point! Each of these errors show up as an obtuse 503 status code and require digging into the istioctl proxy config just to get an understanding on what’s going on in the backend. 

Even more frustrating, the configuration of your service may have been fine without TLS termination. Ingressing through a TCP port to a TCP port on your service for HTTP traffic is fine. But now that you’re using HTTPS, Istio wants to know about what type of traffic you’ll actually be sending. You’ll have to prefix your port names on your service with “http-” in order to tell Istio what you actually are sending over to that service. But Istio’s errors aren’t going to tell you about that.

 

Certificates? DNS?

Let’s say you’ve addressed the issues above. You’ve finally gotten your services to connect from the outside world, your cluster is up and running, and everything finally seems to be working as you expected. But hold on, your ELB just restarted, and now it has a new domain name and a new IP address. Suddenly, traffic is no longer ingressing. Your old DNS records aren’t pointing to the correct host name, and since you’re using TLS now, you can’t just point your customers at your new host name and call it good. 

External DNS management will need to be configured for your cluster to make sure this does not happen, updating the records as your DNS and IP addresses shift. And if your certificates are not renewed, will you be ready with CertManager set up properly in your cluster?

 

Secure Ingress with Aspen Mesh

As described above, setting up secure ingress into an Istio cluster is not as simple as it looks. From configuration issues ranging from mTLS configuration and service port naming, to ever changing environments with DNS and certificate renewals, managing a TLS ingress into your cluster can be a daunting process, especially for new Istio users. The good news? Aspen Mesh can help simplify your secure ingress needs. By simply specifying applications and ports that you’d like to open to the world, and the ports you’d like to ingress on, Aspen Mesh’s Secure Ingress will take care of the configuration for you by: 

  • Setting up and maintaining gateways, virtual services, and authorization policies
  • Providing you with detailed information about possible misconfigurations in your secure ingress

Now doesn’t that seem like a lot of work you’d rather have your system do for you? Reach out to our team of experts if you’d like to learn more about how we can help.