Overview of Grey Matter's Functionality

Grey Matter is composed of Fabric, Data, and Sense. Internal to each component is a series of microservices that offers several core features. Each feature simplifies technical challenges associated with service management, such as:

• Announcement

• Discovery

• Instrumentation

• Logging

Workload Distribution

The following diagram shows the workload distribution between Grey Matter's core components.

Grey Matter Fabric

Fabric powers the zero-trust hybrid service mesh, which consists of the , , , and . You can use Fabric to connect services regardless of language, framework, or runtime environment.

Secure network fabrics provide bridge points, observability, routing, policy assertion, and more between on-premise, multi-cloud, and multi-PaaS capabilities. Fabric offers workload distribution and management within a hybrid environment.

Support for Multiple Runtime Environments

Grey Matter supports multiple runtime environments with multi-mesh bridges as shown below. These environments include:

• Multiple cloud providers (i.e. AWS and Azure)

• Container management solutions (i.e., K8s, OpenShift and ECS)

• On-premise infrastructure

OSI Model Layers

Fabric operates at layers 3 (network), 4 (transport), and 7 (application) simultaneously. Providing a powerful, performant, and unified platform to run, manage, connect, and perform distributed workloads across a hybrid architecture.

Layer 3 operates at the TCP level. Responsible for transferring data “packets” from one host to another using IP addresses, TCP ports, etc., determining which route is the most suitable from source to its destination. At this level, network-segmentation is able to be performed using ABAC, RBAC, and NGAC policies set within each sidecar. More details can be found in the section.

Layer 4 coordinates data transfer between clients and hosts. Adding load balancing, rate limiting, discovery, health checks, observability, and more built on top of TCP/IP. Layer 3 and 4 alone live within the TCP/IP space and are unable to make routing decisions based on different URLs to backend systems or services. This is where layer 7 comes into the architecture.

Layer 7 sits at the top of the OSI model, interacting directly with services and applications responsible for presenting data to users. HTTP requests and responses accessing services, webpages, images, data, etc. are layer 7 actions.

The following graphic shows Fabric's basic capabilities--access, routing decisions, rate limits, health checks, discoverability, observability, proxying, network and micro-segmentation--and how they leverage all features found within each of the OSI layers described above.

Edge

Grey Matter Edge handles flowing through the mesh. Multiple edge nodes can be configured depending on throughput or regulatory requirements requiring segmented routing or security policy rules.

• Traffic flow management in and out of the hybrid mesh.

• Hybrid cloud jump points.

• Load balancing and protocol control.

• Edge OAuth security.

Control

• Automatic discovery throughout your hybrid mesh.

• Templated static or dynamic sidecar configuration.

• Telemetry and observable collection and aggregation.

• Neural net brain.

Security

Grey Matter Fabric offers the following security features:

• Verifies that tokens presented by the invoking service are trusted for such operations.

• Performs operations on behalf of a trusted third party within the Hybrid Mesh.

Sidecar

Add Grey Matter to services by deploying a sidecar proxy throughout your environment. This sidecar intercepts all network communication between microservices.

The Grey Matter Sidecar offers the following capabilities:

• Multiple protocol support.

• Observable events for all traffic and content streams.

• Filter SDK.

• Certified, Tested, Production-Ready Sidecars.

Once you've deployed the Grey Matter Sidecar, you can configure and manage Grey Matter with its control plane functionality.

Grey Matter Control Plane Functionality

• Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic

• Fine-grained control of traffic behavior with rich routing rules, retries, failover, and fault injection

• A policy layer and configuration API supporting access controls, rate limits and quotas

• Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress

Example

The following diagram shows how the Grey Matter Sidecar would operate in a North/South traffic pattern.

Grey Matter Data

Grey Matter Data is an API that enables secure and flexible access control for your microservices. Data consists of Grey Matter Data and JWT server, and includes an API Explorer to help you manage the API.

Grey Matter Sense

Grey Matter Sense consists of four primary components: , , and .

Intelligence 360

Intelligence 360 is our user dashboard that paints a high-level picture of the service mesh. Intelligence 360 includes the following features:

• Mesh Overview

  • Running state of all services

  • Search, sort and filter options

• Historical metrics per service

SLO

Grey Matter Service Level Objectives (SLOs) allows users to manage objectives towards service-level agreements. These objectives can be internal to business operations or made between a company and its customers. They are generic and are valuable in more than one use case.

SLOs combine with Intelligence 360 time-series charts to visualize warning and violation thresholds for targeted performance analysis. These objectives are used even further to train Sense AI for service scaling recommendations.

Business Impact

Business Impact allows users to set metadata on services with the goal of associating how critical a service is towards the operations of a company, mission, or customer. Business Impact provides a list of values (Critical, High, Medium, Low) that correlates each service's business impact. Sense lets users of Intelligence 360 configure these values themselves, which can be used to filter and search via the mesh overview.

Catalog

acts as an interface between the data plane (network of sidecars) of the service mesh and Intelligence 360. Catalog provides a user-focused representation of the mesh.

Learn how to here.

Questions?

Need Help?

Grey Matter consists of a control plane, data plane, mesh, telemetry-powered business intelligence, and AI. It can be deployed on multiple cloud-native or legacy infrastructures without placing predetermined downstream requirements on existing investments.

Learn about the inner workings of Grey Matter's three core components: Fabric, Data, and Sense.

Grey Matter enables unified hybrid microservice deployments and hybrid/multi-cloud operations without special requirements for underlying infrastructure like containers or container platforms regardless of cloud vendor, PaaS or infrastructure.

Questions?

Grey Matter Control performs service discovery and distribution of configuration in the Grey Matter service mesh. Control provides policy and configuration for all running sidecars within the Grey Matter platform.

The Control server works in conjunction with the Grey Matter Control API to manage, maintain, operate, and govern the Grey Matter hybrid mesh platform.

xDS

The Control server performs service discovery in the mesh and acts as an xDS server to which all proxies connect.

xDS is the generic name for the following:

• Endpoints (EDS)

• Clusters (CDS)

• Routes (RDS)

• Listeners (LDS)

Service Discovery

Service Discovery is the way Grey Matter dynamically adds and removes instances of each microservice. Discovery adds the initial instances that come online, and modifies the mesh to react to any scaling actions that happen. To keep flexibility in the Grey Matter platform, the Control server supports a number of different service discovery options and platforms.

The ability to automatically populate instances of a particular microservice comes from the clusterobject. In particular, the name field in the cluster object determines which nodes will be pulled out of the mesh and populated in the instances array. In the example below, the name is catalog. This means that all services that announce as catalog in service discovery, will be found and populated into the instances array after creation.‌

Create the following object:

‌

Will be populated in the mesh as:

‌

Even though the object was created with no instances, they were discovered from the mesh and populated. Now any service that needs to talk to catalog, can link to this cluster and address all live instance.‌

Configuration Discovery

Each proxy in the mesh is connected to the control plane through a gRPC stream to the Grey Matter Control server. Though gm-control-api houses all the configuration for the mesh, it's ultimately gm-control that turns these configs into full Envoy configuration objects and sends them to the proxies.‌

The configuration in the Control API is mapped to physical proxies by the name field in the proxy API object. It's very important that this field exactly match the service-cluster identifier that the intended target proxy used when registering with gm-control.

In the example below, the proxy object, and all other objects linked by their appropriate keys, will be turned into a full Envoy configuration and sent to any proxies that announce as a cluster catalog.‌

Services that announce as:

‌Will receive the config form the object below, because XDS_CLUSTER==name, and they're both in the same zone.

Questions?

Grey Matter is a zero-trust hybrid mesh platform built using open architecture and mesh app and service architecture (MASA) principles.

Each microservice within Grey Matter runs and scales independently to improve secure interoperations, resiliency, continuity of operations, and insight for your business. Our omnichannel support provides rich, fluid, and dynamic connections between people, content, devices, processes, and services.

Core Architectural Principles

Our core architecture principles support the following business needs.

Security

Designed to operate using a zero-trust threat model to ensure each service running within a Grey Matter enabled hybrid mesh is appropriately secured, observed, and managed.

Portability

Enable on-premise, multi-cloud, and multi-platform as a service (PaaS) runtime environments.

Cloud-native

Built with elasticity, high availability, and cloud computing models in mind - provides a unified mesh platform to build applications as microservices, utilize container management solutions, and dynamically orchestrate workloads across hybrid enterprise.

Web-scale

Provides a solid foundation to scale with the growth of your business. Enabling modern architectural patterns supporting rapid increase or decrease in traffic volume, maintaining business insight for effectiveness and efficiency, and aiding in the reduction of bottlenecks when the time matters.

Modular

Modular service delivery - enabling loosely coupled systems and services developed independent of each other, taking advantage of continuous delivery to achieve reliability and faster time to market.

Interoperability

Creates a secure unified zero-trust network fabric, allowing systems to interchangeably serve or receive services from other systems providing enterprises the ability to perform multi-environment segmentation and observe traffic flows between environments. Managed through a runtime environment agnostic Grey Matter Control API.

Adaptive

Able to react to digital business changes, providing a pathway enabling business insight, security, and connectivity across multiple environments reducing complexities while increasing and facilitating a business's digital transformation journey.

Intelligent

Use of artificial intelligence (AI) techniques simplifying and assisting a user experience while providing business insight and fleet wide management across Grey Matter connected resources.

Automation

Integration into any ecosystems and end-to-end automation through the lifecycle of the mesh app and service architecture.

Questions?

The Grey Matter Sidecar is a L7 reverse proxy based off of the popular Open-Source Envoy Proxy. Grey Matter's proxy enhances the base capabilities with custom filters, logic, and the ability for developers to write full-featured Envoy filters in Go.

Fabric Mesh

The primary use of the Grey Matter Sidecar is to act as the distributed network of proxies in the Grey Matter Fabric service mesh. In this use-case; each proxy starts out with very simple configuration, which is then modified by the control plane to suit the changing needs of the network. The documentation here is focused on the individual proxy itself; low-level configuration, filter specifications, etc.

How does event auditing work?

Individual Service

At the level of the individual service, event auditing works as follows:

1. One proxy collects all metrics that happen on the individual service.

2. At the Edge, they extract the PKI/cert.

3. The user that has accessed the service from outside Fabric is then decomposed based on one of the observable fields emitted by the Sidecar proxy.

4. This information, coupled with IP address information from the originating request, is added to the stack of the

Service-to-Service

At the service-to-service level, the sidecar tracks service-to-service calls within Fabric. This enables architecture inference and service dependency observation.

Observable Indexer

Grey Matter also has an observable indexer which can capture geolocation info and move it into Elasticsearch. Customizable event mappings are also available. These can be tailored per individual route so that a POST request may result in an EventAccess event in one route, while resulting in EventCreate on another.

Questions?

Service meshes, microservices, server-less, and containers are key elements of Mesh application and service architecture (MASA) implementations. MASA, APIs, and internal traffic patterns represent one of the most effective pathways to enterprise modernization, but this doesn’t come without challenges.

Industry has signaled increased interest in zero-trust infrastructure for service-to-service mTLS connections, scheduled or on-demand key rotations, service cryptographic identifiers, observability (continuous monitoring, granular audit compliance, etc.), service-level management, and policy management throughout the enterprise service fleet.

Security Models

Understanding how the roles of Authentication, Authorization, Claims, and Principals will play within your MASA is important (figure 1). Authentication and authorization are both significant in any security model, but follow different concepts and implementation patterns. Authentication establishes and confirms an identity. Authorization takes action based on the confirmed identity authenticated. Principals are asserted claims that provide entitlements granting access to systems, services, or data based on Role-based Access Control (RBAC), Attribute-based Access Control (ABAC) and Next Generation Access Control (NGAC) controls.

Authentication

Grey Matter's authentication scheme establishes identities for every transaction within the platform. There are two types of identities: users and services.

User Authentication methods:

• OpenID Connect (OIDC)

• mTLS x.509 certificates (Distinguished names represent who the user is)

Service-to-Service Authentication methods:

• mTLS x.509 certificates (SPIFFE identities are incorporated into the x.509 certificate)

While distinct, these identities are not mutually exclusive. One of the most common access patterns within Grey Matter is a service making a request to another service on behalf of a user. In this case, there are three identities (two services and a user), each of which must be verified in order for the transaction to succeed. As users or services authenticate with Grey Matter, principals are asserted and flow to upstream services. This ensures that upstream services are aware of the entity (user or service) making a request. Grey Matter supports user authentication and service-to-service authentication methodologies identified below.

User Authentication with an OIDC Provider

Grey Matter integrates with existing public OIDC providers (Google, Github, etc.) or private OIDC providers (e.g., Ory Hydra) to support user authentication. OIDC is an authentication protocol built on top of OAuth 2.0 that allows delegation of authentication responsibility to a trusted external identity provider. Many implementations of OIDC providers are available and support on premise, cloud or as a service via a host of underlying technologies (e.g., LDAP). This sequence diagram (figure 3) shows the OIDC flow within Grey Matter.

1. The client initiates a request to Grey Matter Edge.

2. Grey Matter Edge responds with a 302 HTTP status code used to perform URL redirection, along with a callback URL.

3. Based on the redirect URL, the client initiates a request to the specified OIDC provider.

4. Once the client is authenticated, the OIDC provider responds with a 302 HTTP code (based on the callback URL) and provides an OIDC code.

x.509 Certificates

Grey Matter supports x.509 for both users and for service to service transactions.

1. A client (user or service) initiates a request to a server.

2. The server responds with its server certificate.

   2.1. The client verifies that the server’s certificate is valid based on its certificate information.

3. The server requests the client's certificate.

User Authentication with x.509 Certs

Enterprise IT organizations that have existing public key infrastructure (PKI) in place for user authentication can pass their certifications with requests made to the Grey Matter Edge.

Service Authentication with x.509 Certs

Service authentication, (service-to-service communication), is based solely upon x.509 certificates and mTLS. Grey Matter Fabric is installed with a certificate authority that issues and reissues short- lived x.509 certificates to each sidecar proxy for intermesh communication. Each certificate contains a SPIFFE identity that uniquely identifies the sidecar to which it is issued. No sidecar will accept a connection from any service that does not present a certificate issued by the certificate authority. Like user authentication, these service identities enable authorization.

Note: In cases where requests already contain a signed cookie the edge simply verifies the signature and expiry. If valid, the edge forwards the request. If not valid, the request is treated as unauthenticated.

Authorization

Authorization is the process by which identities (users or services) are granted permission to access resources within the mesh. For example, we may wish to restrict access to a specific resource to a limited set of users, services or data. As an added complication, it is often more desirable to grant or deny access for a resource to entire classes of identities (i.e., administrative users or trusted services). Grey Matter uses the authenticated identities and their attributes to support fine-grained access controls using the following methods:

• Authorization Filters

• Data Authorization via the Grey Matter Data Platform Service

It's important to note that Sidecar-to-Sidecar (service-to-service) authorization follows similar patterns of a user with the exception that sidecar identities typically do not include additional attributes; however, there is nothing precluding the addition of attributes for a sidecar identity.

Authorization filters

Upon choosing an authorization pattern, access control becomes a deployment concern, not a development concern. Allowing microservice developers to focus on business value since their services will not receive any unauthorized request. Authenticated identity and attributes are available to the service should they be required.

The Grey Matter Sidecar uses authorization filters to manage who is allowed to access which resources and how. Since all requests to the mesh are authenticated, filters can be dynamically configured at runtime with no additional requirements. Attribute based authorization is also implemented via Grey Matter Sidecar filters but requires that requests contain a signed JSON Web Token (JWT) containing the identity claims. The creation and population of these tokens is left to the enterprise.

List Authorization Filter

The Grey Matter Sidecar supports list-based authorization decisions within the ListAuth filter. This filter allows whitelisting and blacklisting of individual identities based upon the identities distinguished name (i.e, “cn=user, dc=example, dc=com” or “cn=web server, dc=example, dc=com”) or relative distinguished name (i.e., “dc=example, dc=com”). This filter applies to all requests for the proxied service or services.

Role-Based Access Control Filter

The Grey Matter Sidecar supports fine grained authorization decisions to authorize actions by identified clients using Role-Based Access Control (RBAC). This filter allows complex whitelisting and blacklisting of individual identities based upon the identities distinguished name. Matching of regular expressions is supported to add additional flexibility. Further, whereas the ListAuth filter applies to all requests, the Role Based Access Control Filter can be defined for any combination of service, route, or verb. This is useful to explicitly manage callers to a service running within the Grey Matter mesh platform and protect the mesh from unexpected or forbidden agents.

Supported HTTP verbs include:

• GET The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.*

• POST The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.*

• PUT The PUT method replaces all current representations of the target resource with the request payload.*

Definitions as described by the Mozilla Developer Network (MDN).

In situations where the identity is not sufficient to make all authorization decisions, the Grey Matter Sidecar can enforce finer-grained control based upon identity attributes, provided the request contains a sign JWT.

Using the RBAC filter, rules can be created to authorize specific claims found within a JWT to perform specific actions. This requires an external service to generate a signed JWT for each request. Since the JWT is included as a header, if a JWT is passed, it will propagate to all sidecars in the request chain. With that said, if the request is completed—meaning the destination service has received it, processed it, and invokes another service in the Mesh—this is a new request and the calling service would be required to pass the JWT for further authorization purposes.

Custom Access Control Filter

The Grey Matter sidecar offers a custom filter interface, so customers have the ability to create business-specific logic around their security and regulation concerns if required. This makes the mesh fully adaptable to an enterprise’s needs, and provides a way to take advantage of existing IT investments.

Data Authorization

One of the unique facets of Grey Matter is that data security and sharing is addressed by Grey Matter Data. As enterprises shift from monoliths to microservices, data tends to be duplicated across the architecture. Grey Matter Data provides a service to address the secure sharing of this data without marshalling it into and out of processes. This feature is described in greater detail in the Data Segmentation portion of this document, but the pattern employed by Grey Matter Data can be used by any service to enforce complex security policies for any resource via the Grey Matter JWT Security Service or customer JWT service adhering to the Grey Matter Data interface.

Traffic Patterns

One key feature of the Grey Matter hybrid mesh is its ability to secure, manage, and govern the traffic patterns of running services.

East/West Traffic

East/West traffic within the Fabric Mesh should be done via mTLS. Grey Matter uses two methods enabling this: direct integration with existing CAs and, automatic setup via SPIFFE/SPIRE. For integration with existing CAs, each sidecar in the mesh is configured to use provided x. certificates. In the automatic setup, each sidecar uses a unique SPIFFE ID to authenticate with SPIRE servers. Unique short-lived x.509 certificates are then automatically created and rotated for each connection between sidecars.

North/South Traffic

North/South traffic patterns use the Grey Matter Edge to establish principals and pass them to called services. The Edge supports both OIDC and mTLS x.509 certificate authentication modes, however, the Fabric Mesh is not limited to a single Edge. Multiple nodes can be configured to expose both authentication modes wherever an access point is needed. Note that the Edge node does not have to be exposed to a publicly addressable URL. In many cases, an API mediation layer may be put in front of the Edge node. In all cases, the Edge node is responsible for verifying and ensuring that the proper principals are available for downstream services within the Fabric Mesh to consume.

Principals such as user identities are moved by the Edge node into a user_dn header which flows through the entire service-to-service request chain. Each following link in the request chain is performed via mTLS, with each unique service using automatically rotating x.509 certificates established via SPIFFE Identities and the SPIRE framework.

In some cases traffic needs to flow outside of the mesh. Common scenarios include mesh-to- mesh communications, proxying to serverless functions, and supporting legacy systems that can’t be moved directly into the mesh. In all these cases, proxies are setup within the mesh with the sole purpose of communicating outside. Principals are established at the Edge. Inter-mesh communication is still handled by mTLS, and requests are authenticated via the outside system by whatever method it accepts: RPC, HTTP, mTLS, or OIDC.

Traffic Splitting

Traffic splitting is another important pattern in stable environments. Traffic splitting allows configurable service requests to siphon off percentages of requests to another source. This allows services, apps, or entire meshes to experience small amounts of live traffic while keeping most users on the original source. The percentage of users on the original service is then decreased until the service is fully migrated.

Circuit Breaking

Circuit Breaking is a way for each sidecar to protect the thing it is proxying to, but it is not a way to have that proxy harden itself. Grey Matter provides circuit breakers at every point in the mesh.

The most common place for this to occur is at the edge, where a DDOS could overwhelm the edge nodes themselves. To solve this, we employ Rate Limiting, which can protect the edge node from accepting too many requests and opening too many file handles and crashing. With proper configuration, each sidecar ceases queueing new requests before they’re overwhelmed, allowing the service time to heal. This ensures capabilities can withstand malicious attacks and accidental recursive network calls without going down.

Network Segmentation

Enterprises prefer hybrid environments capable of leveraging unified on-premise and cloud resources. Traditional networking patterns use features such as VLANs to create perimeter-based firewalls, but this concept breaks down with modern mesh application service architecture (MASA) patterns. In MASA, services are designed to be ephemeral, dynamically generating different IP:PORT pairs each time a new instance spins up.

Securing this type of architecture requires network segmentation. Grey Matter isolates services and network fabric communications to specific runtime environments or infrastructure resources. Grey Matter Fabric supports segmentation to a very fine level of granularity. Each service launched onto Fabric comes online with no knowledge of or connections to any other point on the mesh. The desired mesh is then built up through configuration with the required network topology. Segmentation is enforced through routing rules, service discovery, and mTLS. Dynamic configuration can facilitate any permutation of intra-mesh communication required. In addition to segmentation of individual meshes, Grey Matter can also support multi-mesh operations. This allows the bridging of environments already physically or logically isolated from each other.

Micro-segmentation

Micro-segmentation is a method of creating secure isolation zones either on-premise or in the cloud in order to separate different workloads. Authentication plays a key role in micro-segmentation. Authentication is responsible for establishing network communications and flow through the mesh. Strong authentication models enable Grey Matter to perform micro-segmentation for users, services, and data throughout the mesh.

User-to-Service segmentation is controlled through user authorization signatures. These can be coupled with claim-based assertions. User identities and claims flow through mTLS-encrypted communication channels established by service-to-service micro-segmentation patterns. Complex security policies within each sidecar allow ABAC/RBAC down to the service, route, and HTTP verb permit. This enables a very high degree of isolation. ABAC/RBAC policies cannot be achieved without strong authentication methodologies establishing identities for both users and services.

Service-to-Service segmentation is controlled through mTLS certificates and SPIFFE identities. These can be coupled with claims-based assertions and ABAC/RBAC policies. Images in the following section illustrate how this is achieved.

Data Segmentation

Grey Matter’s data segmentation capability is a key differentiator. Data segmentation is the process of dividing data and grouping it with similar data based on set parameters. Grey Matter Data adds complex policy assertions to stored objects. These object policies govern which users or services may access the objects. Objects stored within Grey Matter Data are encrypted at rest and in transit. A JSON Web Token (JWT) is provided to gain access to an object stored in Data.

The token’s claims are dynamically mapped to the policies stored with the object. JWTs for both users and services can be created enabling end-to-end security using authentication principals.

The example above shows how data-segmentation is achieved through simple policy. However, the Grey Matter Data policy engine is designed to deal with complex rules designed to suit any scenario. The following scenario presents a more complex use case.

1. Sidecar A saves an object into Data and provides access privileges to Sidecar B’s SPIFFE identity. Sidecar A dynamically discovers Data via the Data Sidecar routing information.

2. Data Sidecar receives Sidecar A’s request and streams the object (with policy) into the Grey Matter Data node.

3. Sidecar B (through a means of event-based architecture patterns) is notified that Sidecar A just saved an object of interest into Data. Sidecar B calls into Data (through the Data Sidecar) to retrieve the object. Sidecar B’s SPIFFE identity is passed along with the request.

   3.1. Data Sidecar receives the request from Sidecar B and passes it to Data. Data uses the Sidecar B principal (i.e. SPIFFE identity) to receive Sidecar B’s JWT claims and authorize access to decrypt and retrieve the object.

Since Grey Matter uses a unified principal model, data segmentation can be achieved for users as well. Grey Matter Data policies can be set to identify different access privileges for services and users on a single stored object, and can be customized around business needs. This paradigm provides a new model that combines network, information assurance, and protection concepts around zero-trust.

Grey Matter Data supports the ability to host multiple Data nodes available through different routing rules. When coupled with other segmentation features, enterprises are able to further isolate how information is stored, accessed, and controlled based on customer regulations and requirements.

For example, logs and observable traffic can be isolated based on zones. Data nodes with specific routing rules and policies are set to enforce the topology. Customer application data can be stored and accessed via different Data nodes (on-premise or in the cloud) and tightly controlled at the micro-segmentation layer or via data policies. These types of flows are depicted in the diagram below.

Conclusion

Grey Matter’s zero-trust threat model ensures security across every service in the hybrid mesh. Each transaction is authenticated and authorized through a combination of mTLS and SPIFFE authentication and SPIRE authorization providing multiple layers of zero-trust security. Grey Matter also supports fine-grained access control by combining authenticated identities with policy-enforced object authorization and enables East-West and North-South traffic pattern splitting and shadowing for in-depth monitoring and configuration. Finally, Grey Matter uses network and data segmentation to decompose operations to their most basic elements, to mitigate cyber intrusion impacts, and to optimize operations.

Questions?

Simple Deployment Model

In the simple deployment model, there is a single point of ingress between the Client and the Grey Matter Edge. The Edge routes traffic to appropriate Grey Matter Sidecars.

Multi-Mesh Deployment Model

The multi-mesh deployment model extends the simple deployment model by allowing each mesh egress to communicate with another mesh ingress using mTLS, as shown below.

Questions?

Data

Grey Matter Data is a microservice for the versioned and encrypted storage of media blobs and assets. It is a high-performance time-series object storage. It contains an immutable sequence of events which collectively describes a file system at a given moment in time. If the first event is a creation of an object and the second is its deletion, then the object will not appear in listings as of the current time, but it will appear as of any time after the creation and before the deletion.

Questions?