mTLS Authentication for Microservices Security is Critical to Digital Transformation

For an enterprise, mentions of “Cloud Native” and “Digital Transformation” are two ways of saying that a service mesh deployment is on the cards. Once deployed, the service mesh forms the backbone of business operations and is usually paramount to business continuity. As an enterprise starts to implement its Digital Transformation plan and migrates from a monolithic application environment to a cloud native application environment, security becomes an immediate concern. From a business operations and revenue generation perspective, it is important to understand the benefits and deployment pitfalls of mTLS to ensure business-as-normal operation. 

Here are some common issues we run into all the time

  • Loss of Regulatory Compliance: Several industries such as healthcare and financial services require compliance with mandated specifications, with many other industries complying with agreed best practices. If compliance is lost, then business operations may be affected if regulatory compliance is lost. A solution to this headache is to enforce mutual TLS STRICT mode as default. This will help to regain regulatory compliance by ensuring end-to-end security for all devices and services
  • Loss of Brand Reputation: Customer or internal proprietary information may be made public via exposure from a security breach. Customers may choose to do business with a more secure supplier consequently. A customer or supplier is unlikely to look favorably upon their chosen supplier or vendor if highlighted on the evening news for example. By enabling mutual TLS GLOBAL setting as default will help to protect your reputation by securing customer and proprietary information. 
  • Loss of Business Agility: With dynamic cloud-based applications, upgrades to business logic, services and offerings can seem endless. Frequent security enhancements are also essential. Upgrades come with their own headaches and can slow a business from rolling out new services due to various glitches. It’s best not to rely solely on perimeter defenses, regain agility by securing critical core applications and services with end-to-end security. 
  • Loss of Business Confidence: The service mesh enables many end-users. If one supplier or service has a loss of confidence in the integrity of the service mesh, this can affect everyone -- and other services. The ability to visualize service communication can help to restore confidence by reducing misconfigurations and simplifying troubleshooting. 

 

In our experience at Aspen Mesh, deploying mutual TLS has many benefits, but is easy to misconfigure – which can lead to severe disruptions to business continuity when deploying new microservices or upgrading a service mesh. Download our new white paper, Istio mTLS: 8 Ways to Ensure End-to-End Security, to learn about several more mutual TLS concerns that could spell disaster for your business! 

 

- Andy 


Istio for multi-cluster deployment: Q & A with an expert

Q&A with Brian Jimerson, Solutions Architect and Istio and multi-cloud deployment expert

I recently had a sit down with one of our Aspen Mesh expert Istio engineers to answer some questions that I hear from customers as they start their multi-cluster Istio journey. If your organization already has a series of disparate single-cluster Istio deployments, real benefits can be achieved by connecting them together to create a multi-cluster service mesh. 

Here are some of the highlights of my conversation with Brian Jimerson, one of our seasoned solution engineers whose experience runs deep optimizing Fortune 2000 enterprise architectures. I wore the hat of a customer exploring the ways moving to a multi-cluster environment might impact performance.

Q: I have stringent SLOs and SLAs for my cloud applications. How can I work to meet these?

Brian: Having multiple Kubernetes clusters in different fault zones can help with disaster recovery scenarios. Using a multi-cluster service mesh configuration can simplify cutover for an event.

Q: As an international company, I  have data privacy requirements in multiple countries. How do I ensure that data is stored in a private manner?

Brian: Using Aspen Mesh's locality-based routing can ensure that customers are using a cluster in their own country, while reducing latency. This can help ensure that private data does not leave the user's country.

Q: I need the ability to quickly scale workloads and clusters based on events. How can I do this in a way that's transparent to customers?

Brian: Using a multi-cluster service mesh can help to scale clusters out and in without interruption to users. A multi-cluster service mesh acts like a single cluster service mesh to services, so communication patterns remain unchanged.

Q: I have compliance requirements for workloads, but they also need to be accessed by other applications. How do I do this?

Brian: Using a multi-cluster service mesh, you can operate compliance workloads in a hardened cluster, and securely control traffic to those workloads from another cluster.

 

I encourage you to read the full paper, Advantages of Going Multi-cluster Using Istio -- and Best Practices to Get There. The move to a multi-cluster environment is complex and there are many things to consider. Working with Brian and our Aspen Mesh Solutions team, I've written a a deep-dive paper that spells out both the advantages and things to look out for when evaluating a move to multi-cluster. There are some disadvantages you have to weigh, and I detail those along with the expected performance improvements that come with deploying a multi-cluster service mesh. In this paper I lay out the benefits and important considerations when considering migrating to a multi-cluster that leverages Istio.

Enterprise-class Istio service mesh is all we do at Aspen Mesh by F5. We offer Professional Services and 24/7 Support plans to give you the ability to tap Istio expertise to optimize your microservices environment with industry best practices, then have peace of mind that we're backing you up. Get in touch if you seek a trusted advisor to help you navigate your OS Istio -- we've designed Istio solutions for some of the largest organizations in the world. I encourage you to get in touch if you would like to talk with Brian, a Solutions Architect who can answer any questions you have about how to chart a toward a cloud native environment. If you want to learn more about our full suite of Services delivered by our team of Istio experts (whether you have OS Istio in pre-prod or production), reach out.

 

-Andy


Recent security vulnerabilities require Zero-Trust Security tactics for your microservices environment

Despite significant technological advancements, security is still hard. A single phishing email, missed patch, or misconfiguration can let the bad guys in to wreak havoc or steal data. For companies moving to the cloud and the cloud-native architecture of microservices and containerized applications, it’s even harder. Now, in addition to the perimeter and the network itself, the myriad connections between microservice containers must also be protected. 

With microservices, the surface area of your network vulnerable to attack increases exponentially, putting data at greater risk. Moreover, network-related problems like access control, load balancing, and monitoring that had to be solved only once for a monolithic application now must be solved separately for each service within a cluster, as well as between clusters. 

Zero Trust Security Methodology and Networking Principles

Zero-Trust dates to the 1990’s as a method for “Perimeter-less” security. The main concept behind the methodology is “never trust, always verify” even if the network was previously verified.

  • Networks should always be considered hostile 
  • Network locality is not sufficient for deciding trust in a network 
  • Every device, user, and request should be authenticated and authorized 
  • Network policies must be dynamic and calculated from as many sources of data as possible
     

Today, it’s essential to apply a Zero-Trust approach to network security and to service mesh technology. In our white paper just completed, Zero-Trust Security for your Microservices Architecture, we outline what it takes to implement the key tenets of Zero-Trust security using a service mesh to secure a microservices environment. In the paper we provide the steps to mitigate cyberattacks to protect containerized applications. 

What's covered in our white paper, Zero-Trust Security for your Microservices Architecture:
  1. Zero-Trust authentication methodology for a service mesh
  2. mTLS encryption: Achieve non-repudiation for requests without requiring any changes or support from the applications. Identity, certificates, and authorization to ensure “every device, user, and request is authenticated and authorized” -- a Zero Trust principle
  3. Learn the built-in methods Istio uses to combat security vulnerabilities
  4. Ingress and Egress security control within a service mesh


Lastly, in the paper we touch on Aspen Mesh’s approach to Zero-Trust security, including how we configure mTLS, secure ingress, monitor egress, prevent RBAC (Role Based Access Control) misconfigurations and apply policy and configuration best practices.

Aspen Mesh has deep expertise in Istio and understands how to get the most out of it - our Services and 24/7 Service Mesh Support are unmatched in the industry.

- Andy


Get a complimentary health check of your os istio graphic

Get a Health Check Report of your Istio to see if everything's configured and optimized.

How do you know your Open Source Istio is operating at its full potential? At Aspen Mesh, we focus on optimizing Istio-based service mesh for our customers (service mesh is all we do).

We talk to companies every day about their OS Istio, and the most common question we get is, “How do we know we’ve got everything in our Istio implementation working correctly?” Whether you’re in a pre-production environment, have Istio deployed in a portion of your network, or network-wide, there's often a fear something’s not configured correctly or there's a potential problem lurking that you don’t have the insight to head-off. Just as importantly, we're asked if there is enhanced Istio functionality to leverage that can drive better performance.

At Aspen Mesh the first thing we do for a new customer is a 360-degree health check of their Istio implementation. It’s a lot like a 100-point diagnostic inspection for your car – a way to identify what’s working fine, where there are potential problems, and get recommendations from an expert about what’s critical to address immediately.

That got us thinking, we should give everyone this level of insight into their Istio implementation.

Aspen Mesh Now Offers a Complimentary OS Istio Health Check Report. This evaluation provides insight across all key areas, identifies critical issues, directs you to best practices, and recommends next steps. You receive an assessment of your Istio by our Istio experts. This is the same evaluation we conduct for every new Aspen Mesh customer running Istio.

A few things that are covered in the Report:

  • Platform: Ensure a stable foundation for smooth version upgrades.
  • Security: ID security risks & apply best practices.
  • Ingress/Egress: Know you’re following best practices.
  • Application Policy inspection
  • Recommendations about where to optimize your performance.
  • Steps to take to go live with confidence.

You Receive your Report After it is Complete

Our Istio expert will review the report with you and recommend remediation steps for critical items discovered – and answer any questions you have. There's no obligation and the Report typically takes about 2 business days. After the review, we give you with a copy of your report. If you want to learn how we work to tackle any Istio problem you have and optimize an Istio environment, we can also share how to take advantage of Aspen Mesh's array of customized Services and Aspen Mesh 24/7 white glove Expert Support for OS Istio.

Where we get the data about your Istio to build your Report
The Aspen Mesh Istio Inspection Report analyzes your Istio system for common misconfigurations and vulnerabilities.

The Report is done in 3 easy steps:

  1. You run the Aspen Mesh Data Collector tool on a workstation with your Kubernetes context configured. This generates a compressed file with the data collected from your Istio installation.
  2. You upload the compressed data file to the Aspen Mesh site.
  3. Aspen Mesh engineers analyze the data collected and build your customer report that details all of our findings.

The Aspen Mesh Data Collector collects the following data:

  • Kubernetes, Istio, and Envoy versions
  • Node topology (number of nodes, node size)
  • Objects installed in your cluster (Kubernetes and Istio objects)
  • Kubernetes events

Note that the Aspen Mesh Data Collector does not collect any potentially sensitive data such as secrets, certificates, or logs. All data that is collected is securely stored and accessed only by Aspen Mesh. Get in touch if you have questions about the process --  I can send you a link to our Data Collector tool and share how we gather and analyze your data to provide a comprehensive assessment. Just send me a note and I'm happy to connect.

-Steven Cheng, Sr. Solutions Engineer at Aspen Mesh