Aspen Mesh proud to sponsor IstioCon 2022

Presentations on Istio Security, Dual Stack Support & TLS Orig. at IstioCon 2022

Virtual IstioCon starts Monday, April 25th. It's the biggest gathering of the Istio community and a great place to learn and share ideas. Aspen Mesh is a longtime Istio open source contributor--we are a top five Istio Contributor of Pull Requests. We are proud to sponsor IstioCon 2022 for the third year.

We're excited three members of the Aspen Mesh team are presenters this year.

Aspen Mesh presentations at IstioCon 2022

Tuesday, April 26, 10:30-10:40 a.m. EST - A Beginner's Guide to Following Istio's Security Best Practices, Jacob Delgado, Senior Software Engineer
Following the Istio Security Best Practices page is a daunting task for newcomers to Istio. Even experienced operators have difficulty discerning where to begin. In this talk I will present an easy way for beginners to adopt Istio and settings/configuration I recommend based on my experience.  

Tuesday, April 26, 11 a.m. EST - Istio Upgrades, Jacob Delgado, Senior Software Engineer & Sam Naser, Software Engineer at Google
Are upgrades getting easier? How easy is easy enough? Are helm and revision based upgrades catching on? What is still painful? How often do you upgrade? How often would you like to? Are patches easier than minor upgrades?

Wednesday, April 27, 10:40-10:50 a.m. EST - TLS Origination Best Practices, Kenan O'Neal, Software Engineer
Quick dive for beginners on TLS origination to improve security. This talk will focus on settings that may not be expected for new users with a focus on validating settings. I will touch on what settings Istio uses by default and how to configure Destination Rules to correctly check certificates.  

Thursday, April 28, 10:50-11:00 a.m. EST - Dual Stack Cluster Setup, Josh Tischer, Lead DevOps Engineer
Dual Stack support is very limited in today’s cloud ecosystem. Learn how to run/test Istio on a Dual Stack cluster in AWS on both OpenShift 4.8+ and KubeAdmin. OpenShift 4.7+ is one of the few options that officially support Dual Stack mode for bare metal clusters and Azure. I am excited to share Aspen Mesh’s experience and empower your team with another option for Dual Stack support. 

You can explore the full list of IstioCon sessions here and be sure to register for IstioCon today

About Aspen Mesh
Enterprise-class Istio service mesh is all we do at Aspen Mesh by F5. We offer Professional Services and 24/7 Support plans to ensure you have OS Istio experts available when you need them. 

Explore our Service Mesh Knowledge Hub for the latest resources on how OS Istio drives performance from your microservices architecture. Deep dive white paper topics include: Multi-cluster deployment to enable hybrid and multi-cloud architectures, security, mTLS, compliance and more.  

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 

Solve Istio Security Risks and Get a Handle on Regulatory Compliance

Many verticals, such as Financial services, Healthcare, Insurance, Transportation and Government contracting are highly regulated industries that must adhere to strict Information Technology (IT) compliance requirements. Each industry has unique certification and compliance requirements, for example HIPAA for Healthcare, PCI-DSS for Payment cards, and SOC2 for the Financial services industry.  

Failure to certify against a compliance regulation can mean a Chief Information Security Officer (CISO) or Chief Compliance Officer (CCO) may not be able to authorize a deployment, microservices upgrade or the addition of new services to an existing service mesh deployment. Achieving compliance with industry requirements is rarely trivial, and at the executive level it is a critical business objective. A compliance requirement raises new security concerns and forces security to be looked at from different angles in any Kubernetes based deployment, old or new. 

Our approach to compliance and security

At Aspen Mesh we work with Fortune 2000 companies to help solve their security and compliance concerns. Our certified Istio experts address many inquiries relating to security, some are related to bare-bones security capabilities and management, and the other are related to specific requirements for individual workloads. Most security related inquiries have a compliance requirement at their core. Simply put, compliance drives security requirements, and thus security headaches. We often see the security issues and concerns raised during converting monolithic applications or environments to cloud-native apps running in a Kubernetes environment as part of a digital transformation initiative.  

Security for compliance is best architected up-front during this transformation process to make compliance a central focus for the design and deployment, especially where existing legacy or hybrid transition steps are planned. 

Goal: Design-in regulatory compliance from the start

  • Simplify deployment and save time by short-circuiting compliance issues up front. 
  • Preserve operational capability of legacy IT elements and associated data. 
  • Gain immediate security benefits by securing compliant workloads from the get-go. 
  • Save time on backend deployment headaches through better tools, visibility, dashboards, and auditing capabilities. 

Istio addresses common security problems out of the box

SOC (Security Operation Center) 2 compliance from the American Institute of Certified Public Accountants, are a series of industry-recognized standards for cloud service providers, software providers and developers, web marketing companies and financial services organizations. Section CC6.6 of SOC2 specifies that unauthorized network connections must be detected. A service mesh can be useful here as it restricts interactions between microservices and automatically generates audit logs to allow you to determine who did what and at what time forming the basis of mandated Auditing tools. 

Similarly, the Health Insurance Portability and Accountability Act (HIPAA) modernized the flow of healthcare information and stipulates how personally identifiable information maintained by the healthcare and healthcare insurance industries should be protected from fraud and theft. A service mesh helps to solve the top four most reported HIPAA violations: 

  • Unauthorized access  
  • Lack of cryptography policy  
  • No proper notification of affected parties and public officials following relevant data breaches 
  • Lack of willingness/capability to update, upgrade or address existing compliance gaps. 

Istio based service mesh streamlines the regulatory compliance process in a Kubernetes environment

Istio provides Security by default as no changes are needed to re-code applications and infrastructure. Achieving defense in depth requires integration with existing security systems to provide multiple layers of defense. A Zero-trust network is fostered by building security solutions on distrusted networks to provide each service with strong authentication and authorization to enable interoperability across clusters and clouds. Istio secures service-to-service communication and provides a management system to automate key and certificate generation, distribution, and rotation.  

Traffic encryption and flexible service access control is achieved through mutual TLS (Transport Layer Security) connections and fine-grained system access is facilitated through RBAC (Role Based Access Control). Sidecar and perimeter proxies work as Policy Enforcement Points (PEPs) to secure communication between clients and servers, including a set of Envoy proxy extensions to manage telemetry and auditing. Peer authentication is used for service-to-service authentication to verify the client making the connection. Istio offers mutual TLS as a full stack solution for transport authentication, which can be enabled without requiring service code changes. 

Eight ways Istio helps you achieve regulatory compliance

  1. End-to-end security 
  2. Granularity of security 
  3. Secure integration with legacy components 
  4. Compliant workloads run in compliant environments 
  5. Visibility to configuration changes 
  6. Dashboard reporting 
  7. Audit logs 
  8. Enable Continual Compliance 

Istio is key in your move from monolithic services to a modern microservices environment

Istio can form a central part of your move from a monolithic services system to a modern Kubernetes based microservices architecture, preserving the ability to use legacy elements. Istio provides all the hooks and handles needed to overcome security issues that cause compliance headaches, to help you achieve compliance faster – which means a quicker deployment with fewer problems and getting a step closer to continual compliance operations. 

  • Compliance requirements drive the need behind most security issues 
  • Istio provides the basis for compliance in a Kubernetes environment 

Checklist for Compliance in a Microservices World

3 Steps to help you put your compliance house in order

1. Architectural review 

  • Have compliant and noncompliant workloads been separated? 
  • Are your compliant workloads running in compliant environments? 

2. Prepare legacy elements for connection to the service mesh 

  • Are the connections to the legacy elements secure? 
  • Are microservices restricted to specific legacy elements?

3. Configure Istio for compliant operation 

  • Are the built-in security features enabled? 
  • Are the mTLS settings correct for your environment? 

About Aspen Mesh

Our experts understand what is necessary to achieve regulatory compliance. We have a team of seasoned Istio experts, and there is no one better at solving Istio security issues and relieving compliance headaches. 

  • Aspen Mesh is a top 5 contributor to the Open Source Istio project – we help shape OS Istio. 
  • Aspen Mesh has deployed service mesh projects in the world’s largest and most complex organizations. 
  • Aspen Mesh visibility tools and dashboards will help you to achieve Continual Compliance. 
  • Reach out to an Aspen Mesh expert for an architectural review and security audit 

Get in touch and we can talk about the compliance issues you are facing. We will share what we’ve done at Fortune 2000 companies to help them achieve their regulatory compliance goals. 

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

Istio mTLS: 8 Ways to Ensure End-to-End Security

Every time an mTLS problem arises, it has the potential to cause a deployment or service outage. 

Mutual TLS (mTLS) is a method of ensuring traffic is authenticated and encrypted between Kubernetes services. In a highly distributed cloud-native system, using mTLS can drastically increase your security posture by eliminating impersonators, bad actors, and traffic snooping. However, this comes with additional complexity, and troubleshooting issues can be challenging.   

Implementing mTLS is often done with a sidecar service mesh like Istio. Istio supports mTLS out of the box, but in our experience the default configuration is not enough. 

Simple configuration changes are often all that is needed to solve the most taxing of issues.  

The Aspen Mesh team has experience helping our customers deploy mutual Transport Layer Security (TLS) across a wide range of industry verticals and situations. 

8 ways to mitigate risk when deploying mutual TLS:

1. Enforce STRICT mode as a default

Why it’s important: Ensures end-to-end security for all devices and services. 

PERMISSIVE mode allows a service to accept both plain text traffic and mutual TLS traffic at the same time. This feature greatly improves the mutual TLS onboarding experience; however, this mode is not as secure as STRICT mode. When STRICT is set, the service only accepts mutual TLS traffic. For services with transport authentication enabled by an authentication policy, the peers section has an additional key (mode), which you can use to define which traffic a service can accept from its peers. This mode key can take two values: PERMISSIVE or STRICT. If PERMISSIVE is set, the service can accept both plain-text traffic as well as encrypted. If STRICT is set, the service only accepts mutual TLS traffic. 

In Istio, sidecar proxies for each service are needed to establish mutual TLS communication. However, during a service onboarding process there may be cases where the operator cannot install sidecar proxies for all clients and services at the same time. In these situations, it is ideal to enable communication between non-Istio client services and Istio target services. By enabling the PERMISSIVE mode in the authentication policy for a target service, non-Istio client services can continue to send plain-text traffic to the target service until the onboarding process is complete, when STRICT can be enabled. 


2. Enable mutual TLS global by default

Why it’s important: Defines scope of mutual TLS settings. 

There are three levels of granularity through which mutual TLS settings can be defined. For each service, Istio applies the narrowest matching policy. The order is: service-specific, namespace-wide, mesh-wide. It is best to enforce mTLS globally, and then change to PERMISSIVE at the service level only when necessary.   

3. Don’t rely on Perimeter defenses to secure core applications and services

Why it’s important: Greater security and compliance with industry regulations. Perimeter defenses are insufficient; secure critical core services and traffic with end-to-end security. 

Don’t rely on Perimeter defenses to secure your core applications and services. While defense-in-depth has been a valid approach to security, it does not stop an attacker from viewing unencrypted data after the security bubble has been pierced. Only services that are encrypted end-to-end can provide the level of security needed to protect confidential information such as financial transactions or medical records. 


4. Visibility for service communication

Why it’s important: Eases misconfigurations and aids in troubleshooting. 

A visibility tool is paramount to get a picture of what’s happening at the service level. For example, if one service has no sidecar installed, or a service with a sidecar has a service-specific policy set and there is something wrong with communication between services, the cause may be one service has mutual TLS enabled where another service may not support mutual TLS. A visibility tool that runs in real time can help to find problems quickly as they arise, dynamically visualizing services and their communications to ease misconfigurations and aid in troubleshooting. 

5. Enable an external Certificate Authority

 Why it’s important: More easily integrate with external systems.

Although the Istio Certificate Authority (CA) generates a self-signed root certificate/key, and uses them to sign all workload certificates, external parties normally will not trust a digital certificate signed by an Internal CA. Also, the certificate management overhead of an Internal CA is higher than that of external CA. External parties normally trust a digital certificate signed by a trusted External CA easing the ability to work with external services over using an Internal CA. 


6. Optimize System Design – Design for mTLS and service mesh from the start

Why it’s important: Retrofitting system-wide mTLS after deployment of the platform and services is difficult and error prone. Designing for mTLS from the beginning will increase your success rate and ensure that all communication channels are secured properly.  Attempting to implement mTLS after deploying the platform and applications will require reconfiguration of the service mesh, installing and configuring a root CA, redeploying all applications, and regression testing of the applications and external integrations. 


7. Mitigate the mutual TLS performance hit

Why it’s important: Mitigate to restore ideal system performance to prevent services operating at less than optimum levels 

After enabling mutual TLS, depending on the service or workload, a performance hit may be experienced which can affect services. A performance hit up to 10% is possible, but largely depends on the services and workload of the deployment. To mitigate any resultant performance hit, Envoy can be tuned, and the underlying deployment hardware re-sized to restore system performance. 


8. Decrease certificate rotation time

Why it’s important: Enhances security which helps to defeat hackers. 

Istio has a default Certificate rotation time that rotates new Certificates, and encryption keys are issued. However, the longer this rotation interval, the more opportunity an attacker has to defeat the encryption. Set the Certificate rotation time to the minimum rotation time needed for your deployment / services. This helps defeat hackers by shortening the window of time they have to execute “brute force” attacks. 


How can Aspen Mesh help you on your Istio journey?

Aspen Mesh provides the knowledge, leadership & expertise needed to successfully help you deploy mTLS. We have helped customers deploy in the Enterprise, Telco, Financial services, and Healthcare verticals. We have deployed mTLS in complex High Availability and Disaster Recovery environments and provided upfront training before the deployment starts, and expert support after the deployment is complete. We can: 

  • Advocate for your needs within the open-source community 
  • Provide training and expert support 
  • Mitigate your deployment risk with our service offerings, which include: 
  • A 360° quantitative and qualitative evaluation of your Istio environment to identify problems. 
  • Expertise in the design of a scalable service mesh environment. 
  • Comprehensive security review and detailed recommendations. 
  • Upgrade Istio in your environment, then ensure it’s running smoothly. 
  • Existing Istio environment benchmarking and tuning for maximum performance. 


Deployment success means picking the right partner

mTLS can be challenging, integration with external workloads is problematic, and debugging information can be a blackhole. Visibility is essential when something goes wrong in any deployment, but more so in a mTLS deployment. We provide 24/7 and international support delivered by our expert Istio engineers from F5, a trusted enterprise vendor you can rely on. You can be assured our engineers are with you every step of the way, no matter the problem – big or small.  

Aspen Mesh can help fully manage and monitor your mTLS deployment, setting you up for success in the long term. Our team of experts have the knowledge and expertise to guide you every step of the way. See our Professional Services including in-depth Istio Health Assessment, Architecture Design and Security Essentials and Custom Projects. Get in touch to start the conversation.

Adopting a Zero-Trust Approach to Security for Containerized Applications

Adopting a zero-trust secure service mesh can help remove the burden of addressing security requirements from your application development teams, freeing them to focus on functions that provide direct value to your customers. Find out how in this whitepaper along with:

top 5 istio contributors graphic

Aspen Mesh Leads the Way for a Secure Open Source Istio

Here at Aspen Mesh, we entrenched ourselves in the Istio project not long after its start. Recognizing Istio's potential early on, we committed to building our entire company with Istio at its core. From the early days of the project, Aspen Mesh took an active role in Istio -- we've been part of the community since Fall of 2017. Among our many firsts, Aspen Mesh was the first non-founding company to have someone on the Technical Oversight Committee (TOC) and have a release manager role when we helped manage the release of Istio v1.6 in 2020.

Ensuring open source Istio continues to set the standard as the foundation for a secure enterprise-class service mesh is important to us. In fact, we helped create the PSWG in collaboration with other community leaders to ensure Istio remains a secure project with well-defined practices around responsible early disclosures and incident management.

Jacob Delgado of Aspen Mesh has been a tremendous contributor to Istio's security and he currently leads the Product Security Working Group.

Aspen Mesh leads contribution to Open Source Istio

The efforts of Aspen 'Meshers' can be seen across Istio's architecture today, and we add features to open source Istio regularly. Some of the major features we've added include Elliptic Curve Cryptography (ECC) support, Configuration validation (istio-vet -> Istio analyzers), custom tracing tags, and Help v3 support. Aspen Mesh is a Top 5 Istio Contributor of Pull Requests (PRs). One of our primary areas of focus is helping to shape and harden Istio's security. We have responsibly reported several critical CVEs and addressed them as part of PSWG like the Authentication Policy Bypass CVE. You can read more about how security releases and 0-day critical CVE patches are handled in Istio in this blog authored by Jacob.

Istio Security Assessment Report findings announced in 2021

The success of the Istio project and its critical use enforcing key security policies in infrastructure across a wide swath of industries was the impetus for a comprehensive security assessment that began in 2020. In order to determine whether there were any security issues in the Istio code base, a third-party security assessment of the Istio project was conducted last year that enlisted the NCC Group and sought collaboration with subject matter experts across the community.

This in-depth assessment focused on Istio’s architecture as a whole, looking at security related issues with a focus on key components like istiod (Pilot), Ingress/Egress gateways, and Istio’s overall Envoy usage as its data plane proxy for Istio version 1.6.5. Since the report, the Product Security Working Group has issued several security releases as new vulnerabilities were disclosed, along with fixes to address concerns raised in the report. A good outcome of the report is the detailed Security Best Practices Guide developed for Istio users.

At Aspen Mesh, we build upon the security features Istio provides and address enterprise security requirements with a zero-trust based service mesh that provides security within the Kubernetes cluster, provides monitoring and alerts, and ensures highly-regulated industries maintain compliance. You can read about how we think about security in our white paper, Adopting a Zero-Trust Approach to Security for Containerized Applications.

If you'd like to talk to us about what enterprise security in a service mesh looks like, please get in touch!

-Aspen Mesh


istio test stats from

you've got kubernetes promotional graphic

Get App-focused Security from an Enterprise-class Service Mesh | On-demand Webinar

In our webinar you can now view on demand, You’ve Got Kubernetes. Now you Need App-focused Security using Istio, we teamed with Mirantis, an industry leader in enterprise-ready Kubernetes deployment and management, to talk about security, Kubernetes, service mesh, istio and more. If you have Kubernetes, you’re off to a great start with a great platform for security based on Microsegmentation and Network Policy. But firewalls and perimeters aren’t enough -- even in their modern, in-cluster form.  

As enterprises embark on the cloud journey, modernizing applications with microservices and containers running on Kubernetes is key to application portability, code reuse and automation. But along with these advantages come significant security and operational challenges due to security threats at various layers of the stack. While Kubernetes platform providers like Mirantis manage security at the infrastructure, orchestration and container level, the challenge at application services level remains a concern. This is where a service mesh comes in. 

Companies with a hyper focus on security – like those in healthcare, finance, government, and highly regulated industries – demand the highest level of security possible to thwart cyberthreats, data breaches and non-compliance issues. You can up level your security by adding a service mesh that’s able to secure thousands of connections between microservices containers inside of a single cluster or across the globe. Today Istio is the gold standard for enterprise-class service mesh for building Zero Trust Security. But I’m not the first to say that implementing open source Istio has its challenges -- and can cause a lot of headaches when Istio deployment and management is added to a DevOps team’s workload without some forethought.  

Aspen Mesh delivers an Istio-based, security hardened enterprise-class service mesh that’s easy to manage. Our Istio solution reduces friction between the experts in your organization because it understands your apps -- and it seamlessly integrates into your SecOps approach & certificate authority architecture. 

It’s not just about what knobs and config you adjust to get mTLS in one cluster – in our webinar we covered the architectural implications and lessons learned that’ll help you fit service mesh into your up-leveled Kubernetes security journey. It was a lively discussion with a lot of questions from attendees. Click the link below to watch the live webinar recording.



Click to watch webinar now:

On Demand Webinar | You’ve Got Kubernetes. Now you Need App-focused Security using Istio.

 The webinar gets technical as we delve into: 

  • How Istio controls North-South and East-West traffic, and how it relates to application-level traffic. 
  • How Istio secures communication between microservices. 
  • How to simplify operations and prevent security holes as the number of microservices in production grows. 
  • What is involved in hardening Istio into an enterprise-class service mesh. 
  • How mTLS provides zero-trust based approach to security. 
  • How Aspen Mesh uses crypto to give each container its own identity (using a framework called SPIFFE). Then when containers talk to each other through the service mesh, they prove who they are cryptographically. 
  • Secure ingress and egress, and Cloud Native packet capture. 

Delphi Simplifies Kubernetes Security with Aspen Mesh

How Delphi Simplifies Kubernetes Security with Aspen Mesh

Delphi's Mission

Delphi delivers software solutions that help professional liability insurers streamline their operations and optimize their business processes. Leveraging a highly flexible technology platform, Delphi enables companies to reduce costs, increase operational efficiency, and improve business intelligence. The Delphi Digital Platform is a cloud-based software solution that connects customers, agents, employees, and third parties to Delphi’s core transactional systems and other solutions in the digital ecosystem. This provides professional liability insurance carriers with modern microservice-based software solutions, giving them: 

  • The ability to link their business directly to their customers’ needs 
  • The flexibility to quickly respond to changing market conditions 
  • A cloud platform providing an environment for acquisition integration 

Delphi's Technology Stack

The infrastructure team at Delphi has fully embraced a cloud-native stack to deliver the Delphi Digital Platform to its customers. The team leverages Kubernetes to effectively manage builds and deploys. Delphi planned to use Kubernetes from the start, but was looking for a simpler security solution for their infrastructure that could be managed without implementations in each service. 

The Challenge

Operating in the highly regulated healthcare industry, privacy and compliance concerns such as HIPAA and APRA mandate a highly secure environment. A zero trust environment is of utmost importance for Delphi and their customers. Delphi, was getting tremendous value from Kubernetes but needed to find an easier way to bake security into the infrastructure. Taking advantage of a service mesh was the obvious solution to address this challenge, as it provides cluster-wide mTLS encryption. The team chose Istio to solve this problem. The initial solution included setting up a certificate at the load balancer, but this had open http between the load balancer and service. Unfortunately, this was not acceptable in a highly regulated healthcare industry with strict requirements to keep personal data secure.

“At this point, I look at Aspen Mesh as an extension of my team”
- Bill Reeder, Delphi Technology Lead Architect 

The Solution

With the final solution in sight, Delphi engaged with Aspen Mesh to implement an end-to-end encrypted solution, from Client to back end SaaS applications. This was achieved by enabling mTLS mesh-wide from service to service and creating custom Istio policy manifests to integrate cert-manager and Letsencrypt for client-side encryption. As a result, Delphi is able to provide secure ingress integration for a multitenant B2C environment.This approach forwards encrypted AWS Elastic Load Balancer traffic to the Istio Ingress Gateway for TLS connection termination. The solution utilizes DNS resolution via Route53 to allow LetsEncrypt to validate the Certificate Signing Request and issue a certificate to cert-manager.The traffic then traverses one gateway resource per tenant (isolated client hosts) where each gateway contains its own certificate. This solution allows Delphi to deploy its own private key and certificate whenever a new tenant is created in the mesh, generating a fully scalable solution where cert-manager/Letsencrypt provides the certs or keys as desired. 

The Impact

The Aspen Mesh solution lets Delphi use Let’s Encrypt seamlessly with Istio. This has removed the need to consider building security into application development and placed it into an infrastructure solution that is highly scalable. Leveraging the power of Kubernetes, Istio and Aspen Mesh, the Delphi team is delivering a highly secure platform to their customers without the need to implement encryption in each service.