Secure Your Service Mesh: A 13-Item Checklist
Organizations worldwide are rushing to modernize their applications to run in Kubernetes-orchestrated containers in the cloud. During this modernization, these companies must plan to secure their application connections. When an application is replatformed and rearchitected into distributed microservices, new connectivity patterns emerge, and these patterns usually prompt the building of one or more service meshes.
A robust service mesh can handle both north-south connections (ingress to Kubernetes-based applications from the edge) and east-west connections (between services on the same cluster or between different clusters.) However, each of these traffic patterns needs comprehensive security.
The best way to approach service mesh security is to adopt a zero-trust model, which means that every connection, no matter its origin, must be validated and secured. To help you evaluate service mesh technologies and implement zero-trust security, we present our 13 must-have features to keep your application connections safe. Here’s the checklist:
- Transport layer security (TLS & mTLS) provides end-to-end encryption to protect data in motion between any pair of end points. It’s perhaps the most fundamental component, but surprisingly not all service meshes fully support mutual TLS.
- Built-in web application firewalls (WAF) screen inbound traffic for threats and stop attacks from penetrating your perimeter. It’s essential for any edge gateways that are exposed to the internet for incoming user and application connection requests.
- Data loss prevention (DLP) monitors for data breaches or exfiltration to prevent data loss and data leaks. If your applications are somehow compromised, you don’t want data escaping your perimeter.
- Integration with secrets management for Kubernetes, which manages sensitive credentials like passwords, security tokens and encryption keys. You’d be alarmed at how often this information is still hard-coded into applications or stored in plain text.
- Certificate management controls and executes SSL certificates from a centralized platform to authenticate connections. Certificate rotation can be a painful administrative step that should be accounted for gracefully. This should be extensible to support external authorities, meaning it’ll work with the enterprise identity and access management solutions you already use.
- Authorization, for example with Open Policy Agent (OPA), which defines service API policies as code. Authorization is the flip side of authentication and controls who has access to what resources once you’ve verified their identity.
- Federated trust domains safely authenticate users and applications across environments, extending the authentication policies consistently everywhere. Without this, you’ll spend a lot of effort trying to keep various roles updated and in sync — and probably make some mistakes.
- Federated role-based access control (RBAC) and delegation grants permissions to users appropriate to their responsibility and, again, applies this consistently everywhere. These controls can be applied at different levels for operators managing the service mesh and also for developers building applications that run in the mesh.
- Multitenancy and isolation lets users and applications in service meshes share resources securely. Once you have RBAC, you can safely define who can touch what and effectively create isolated workspaces for different roles. Istio’s Authorization Policy can also be used to prevent unwanted traffic from reaching your application.
- Vulnerability scanning and publications find, address and alert on any weaknesses in the system. Security is only as good as its weakest link, so it’s important to check for any gaps in your defenses.
- Multicluster access observability provides complete log aggregation and auditability of all activity across the system. This can be useful both for real-time monitoring and forensics after an incident. With distributed applications, it’s necessary to get a holistic view. Many use open source tools like Prometheus and Grafana for observability.
- Federal information processing standards (FIPs) 140-2 means your service mesh technology has been validated to meet specific strict security standards as set out by the United States government. There are many government regulations and industry best practices, but FIPS is one common way to baseline your security.
- A secure pull model for cluster relay safely shares configurations across the system. This is pretty nuanced, but you want to make sure that any configuration changes are distributed to the edge when requested, and only when requested.
While not strictly a security feature of service meshes, one bonus consideration is the availability of enterprise support and defined service-level agreements (SLAs) for response. Open source software itself doesn’t necessarily meet the bar for production deployments, so you probably want a vendor on standby to help you out. Inevitably there will be issues and when a CVE (common vulnerabilities and exposures) incident is discovered, it is reassuring to know that someone can quickly patch your code and even backport the fix to older versions if you haven’t kept up with the rapid pace of new releases.
For additional context, the Cloud Native Computing Foundation Security Interest Group (CNCF SIG) has published a holistic whitepaper on security recommendations, which serves as recommended reading for anyone undertaking an application modernization project.
Security is one of the core tenets of open source Istio, the most popular service mesh today for Kubernetes. Some vendors have enhanced Istio’s security capabilities even further. However, few can actually deliver every feature mentioned above. We emphatically recommend you use the checklist above to benchmark the technology and policies in your own deployments, ideally when planning your service mesh and critically when you are in production. Stay safe!
