Multi-Mesh Deployments for Isolation and Boundary Protection

Various compliance standards require protection of sensitive data environments. Some of the important standards and the types of sensitive data they protect appear in the following table:

Standard	Sensitive data
PCI DSS	payment card data
FedRAMP	federal information, data and metadata
HIPAA	personal health data
GDPR	personal data

PCI DSS, for example, recommends putting cardholder data environment on a network, separate from the rest of the system. It also requires using a DMZ, and setting firewalls between the public Internet and the DMZ, and between the DMZ and the internal network.

Isolation of sensitive data environments from other information systems can reduce the scope of the compliance checks and improve the security of the sensitive data. Reducing the scope reduces the risks of failing a compliance check and reduces the costs of compliance since there are less components to check and secure, according to compliance requirements.

You can achieve isolation of sensitive data by separating the parts of the application that process that data into a separate service mesh, preferably on a separate network, and then connect the meshes with different compliance requirements together in a {{< gloss >}}multi-mesh{{< /gloss >}} deployment. The process of connecting inter-mesh applications is called {{< gloss >}}mesh federation{{< /gloss >}}.

Note that using mesh federation to create a multi-mesh deployment is very different than creating a {{< gloss >}}multicluster{{< /gloss >}} deployment, which defines a single service mesh composed from services spanning more than one cluster. Unlike multi-mesh, a multicluster deployment is not suitable for applications that require isolation and boundary protection.

In this blog post I describe the requirements for isolation and boundary protection, and outline the principles of multi-mesh deployments. Finally, I touch on the current state of mesh-federation support and automation work under way for Istio.

Isolation and boundary protection

Isolation and boundary protection mechanisms are explained in the NIST Special Publication 800-53, Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations, Appendix F, Security Control Catalog, SC-7 Boundary Protection.

In particular, the Boundary protection, isolation of information system components control enhancement:

{{< quote >}} Organizations can isolate information system components performing different missions and/or business functions. Such isolation limits unauthorized information flows among system components and also provides the opportunity to deploy greater levels of protection for selected components. Separating system components with boundary protection mechanisms provides the capability for increased protection of individual components and to more effectively control information flows between those components. This type of enhanced protection limits the potential harm from cyber attacks and errors. The degree of separation provided varies depending upon the mechanisms chosen. Boundary protection mechanisms include, for example, routers, gateways, and firewalls separating system components into physically separate networks or subnetworks, cross-domain devices separating subnetworks, virtualization techniques, and encrypting information flows among system components using distinct encryption keys. {{< /quote >}}

Various compliance standards recommend isolating environments that process sensitive data from the rest of the organization. The Payment Card Industry (PCI) Data Security Standard recommends implementing network isolation for cardholder data environment and requires isolating this environment from the DMZ. FedRAMP Authorization Boundary Guidance describes authorization boundary for federal information and data, while NIST Special Publication 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy recommends protecting of such a boundary in Appendix G, Authorization Boundary Considerations:

{{< quote >}} Dividing a system into subsystems (i.e., divide and conquer) facilitates a targeted application of controls to achieve adequate security, protection of individual privacy, and a cost-effective risk management process. Dividing complex systems into subsystems also supports the important security concepts of domain separation and network segmentation, which can be significant when dealing with high value assets. When systems are divided into subsystems, organizations may choose to develop individual subsystem security and privacy plans or address the system and subsystems in the same security and privacy plans. Information security and privacy architectures play a key part in the process of dividing complex systems into subsystems. This includes monitoring and controlling communications at internal boundaries among subsystems and selecting, allocating, and implementing controls that meet or exceed the security and privacy requirements of the constituent subsystems. {{< /quote >}}

Boundary protection, in particular, means:

• put an access control mechanism at the boundary (firewall, gateway, etc.)
• monitor the incoming/outgoing traffic at the boundary
• all the access control mechanisms must be deny-all by default
• do not expose private IP addresses from the boundary
• do not let components from outside the boundary to impact security inside the boundary

Multi-mesh deployments facilitate division of a system into subsystems with different security and compliance requirements, and facilitate the boundary protection. You put each subsystem into a separate service mesh, preferably on a separate network. You connect the Istio meshes using gateways. The gateways monitor and control cross-mesh traffic at the boundary of each mesh.

Features of multi-mesh deployments

• non-uniform naming. The withdraw service in the accounts namespace in one mesh might have different functionality and API than the withdraw services in the accounts namespace in other meshes. Such situation could happen in an organization where there is no uniform policy on naming of namespaces and services, or when the meshes belong to different organizations.
• expose-nothing by default. None of the services in a mesh are exposed by default, the mesh owners must explicitly specify which services are exposed.
• boundary protection. The access control of the traffic must be enforced at the ingress gateway, which stops forbidden traffic from entering the mesh. This requirement implements Defense-in-depth principle and is part of some compliance standards, such as the Payment Card Industry (PCI) Data Security Standard.
• common trust may not exist. The Istio sidecars in one mesh may not trust the Citadel certificates in other meshes, due to some security requirement or due to the fact that the mesh owners did not initially plan to federate the meshes.

While expose-nothing by default and boundary protection are required to facilitate compliance and improve security, non-uniform naming and common trust may not exist are required when connecting meshes of different organizations, or of an organization that cannot enforce uniform naming or cannot or may not establish common trust between the meshes.

An optional feature that you may want to use is service location transparency: consuming services send requests to the exposed services in remote meshes using local service names. The consuming services are oblivious to the fact that some of the destinations are in remote meshes and some are local services. The access is uniform, using the local service names, for example, in Kubernetes, reviews.default.svc.cluster.local. Service location transparency is useful in the cases when you want to be able to change the location of the consumed services, for example when some service is migrated from private cloud to public cloud, without changing the code of your applications.

The current mesh-federation work

While you can perform mesh federation using standard Istio configurations already today, it requires writing a lot of boilerplate YAML files and is error-prone. There is an effort under way to automate the mesh federation process. In the meantime, you can look at these multi-mesh deployment examples to get an idea of what a generated federation might include.

Summary

In this blog post I described the requirements for isolation and boundary protection of sensitive data environments by using Istio multi-mesh deployments. I outlined the principles of Istio multi-mesh deployments and reported the current work on mesh federation in Istio.

I will be happy to hear your opinion about {{< gloss >}}multi-mesh{{< /gloss >}} and {{< gloss >}}multicluster{{< /gloss >}} at discuss.istio.io.