Communication Patterns

This page documents some examples of supported communication patterns for workloads using Cofide Connect. Each pattern describes how client and server workloads obtain SVIDs (X.509 or JWT), how connections are established, and what infrastructure is required. Working examples for each pattern can be found in the cofide-demos repository.

X.509-SVID patterns

SPIFFE-native in Kubernetes

Example: ping-pong in cofide-demos

Both client and server retrieve X.509-SVIDs directly from the SPIFFE Workload API via a Unix domain socket or named pipe exposed by the SPIRE agent. The client uses its X.509-SVID as its TLS client certificate and verifies the server’s SVID against the SPIFFE trust bundle for the server’s trust domain. The server similarly verifies the client’s SVID, completing mutual TLS authentication with no long-lived credentials. Traffic is routed via a Kubernetes load balancer service, though an ingress or gateway can be used instead. When client and server are in different trust zones, each side must have access to the other’s trust bundle, established via Cofide Connect federation.

---
title: SPIFFE-native in Kubernetes
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Trust Zone 1]
    group trust_zone_2(cloud)[Trust Zone 2]
    service service_a(server)[Service A] in trust_zone_1
    service spiffe_a(database)[SPIFFE Workload API] in trust_zone_1
    service client_b(server)[Client B] in trust_zone_2
    service spiffe_b(database)[SPIFFE Workload API] in trust_zone_2
    service k8s_lb(cloud)[K8s LoadBalancer Service] in trust_zone_1
    service_a:T --> B:spiffe_a
    client_b:T --> B:spiffe_b
    client_b:R --> L:k8s_lb
    k8s_lb:R --> L:service_a

Istio Proxy Sidecars + Federated Service

Example: ping-pong-mesh in cofide-demos

Both client and server are deployed with Istio proxy sidecars configured to use Cofide SPIRE as the mesh CA. A Cofide Federated Service exposes the server outside of its cluster and enables discovery from the client’s trust zone.

The server runs a plain-text HTTP server, and the client makes plain-text HTTP requests to the federated service hostname. The Istio proxies intercept all inbound and outbound traffic, retrieve X.509-SVIDs from the SPIFFE workload API, and upgrade connections to mTLS transparently to the application. Istio uses ALPN extensions and peer authentication metadata exchange to identify the peer’s SPIFFE ID and enforce policy, without requiring application-level changes.

Cofide Agent provisions the necessary Istio resources to route cross-cluster traffic via an Istio gateway. The Istio gateway operates in AUTO_PASSTHROUGH mode: it routes traffic based on SNI without terminating TLS, preserving end-to-end mTLS between the two Istio proxies.

---
title: Istio sidecars with Federated Service
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Trust Zone 1]
    group trust_zone_2(cloud)[Trust Zone 2]
    group service_pod[Service A pod] in trust_zone_1
    group client_pod[Client B pod] in trust_zone_2
    service service_a(server)[Service A] in service_pod
    service spiffe_a(database)[SPIFFE Workload API] in trust_zone_1
    service istio_proxy_a(cloud)[Istio Proxy] in service_pod
    service client_b(server)[Client B] in client_pod
    service spiffe_b(database)[SPIFFE Workload API] in trust_zone_2
    service istio_proxy_b(cloud)[Istio Proxy] in client_pod
    service gateway(cloud)[Istio Gateway] in trust_zone_1

    istio_proxy_a:B --> T:service_a
    istio_proxy_a:T --> B:spiffe_a
    istio_proxy_b:T --> B:spiffe_b
    istio_proxy_b:R --> L:gateway
    client_b:T --> B:istio_proxy_b
    gateway:R --> L:istio_proxy_a

Server with Istio Proxy and Non-Istio Client (Hybrid Mesh)

Example: ping-pong-mesh in cofide-demos, annotated with spiffe.cofide.io/inject=proxy

The server is deployed with an Istio proxy sidecar which is configured to use Cofide SPIRE as the mesh CA. The client uses spiffe-enable to inject a Cofide Proxy sidecar, enabled by annotating the client pod with spiffe.cofide.io/inject=proxy. A Cofide Federated Service exposes the server outside of its cluster and enables discovery from the client’s trust zone.

The server runs a plain-text HTTP server; its Istio proxy handles all TLS termination and policy enforcement. The client makes plain-text HTTP requests to the server’s federated service hostname. The Cofide Proxy sidecar intercepts these outbound connections and uses the Cofide Agent xDS API to resolve the federated service hostname to the Istio gateway address. Cofide Proxy retrieves its own X.509-SVID from the SPIFFE workload API and upgrades the connection to mTLS before forwarding to the Istio gateway.

Istio mTLS includes custom ALPN and metadata extensions that identify the peer as an Istio proxy and enable peer authentication. Cofide Proxy implements these Istio mTLS extensions, allowing it to connect to an Istio-proxied server from outside the mesh as if it were an Istio peer.

Cofide Agent provisions the necessary Istio resources to route traffic via an Istio gateway. The Istio gateway operates in AUTO_PASSTHROUGH mode, routing traffic by SNI without terminating TLS, preserving end-to-end mTLS between Cofide Proxy and the server’s Istio proxy.

---
title: Server with Istio sidecar, non-Istio client (Hybrid Mesh)
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Trust Zone 1]
    group trust_zone_2(cloud)[Trust Zone 2]
    group service_pod[Service A pod] in trust_zone_1
    group client_pod[Client B pod] in trust_zone_2
    service service_a(server)[Service A] in service_pod
    service spiffe_a(database)[SPIFFE Workload API] in trust_zone_1
    service istio_proxy_a(cloud)[Istio Proxy] in service_pod
    service client_b(server)[Client B] in client_pod
    service proxy_b(cloud)[Cofide Proxy] in client_pod
    service spiffe_b(database)[SPIFFE Workload API] in trust_zone_2
    service gateway(cloud)[Istio Gateway] in trust_zone_1
    service cofide_agent(server)[Cofide Agent xDS] in trust_zone_2

    istio_proxy_a:B --> T:service_a
    istio_proxy_a:T --> B:spiffe_a
    client_b:R --> L:proxy_b
    proxy_b:T --> B:spiffe_b
    proxy_b:R --> L:gateway
    proxy_b:B --> T:cofide_agent
    gateway:R --> L:istio_proxy_a

SPIFFE-native with Istio Federated Service and xDS Client

Example: ping-pong-cofide in cofide-demos

Both client and server retrieve X.509-SVIDs from the SPIFFE workload API and handle their own TLS. Neither is deployed with an Istio proxy. A Cofide Federated Service exposes the server outside of its cluster and enables discovery from the client’s trust zone.

The client uses Cofide SDK Go to query the Cofide Agent xDS API, which returns the resolved endpoint (Istio gateway address and port) for the federated service hostname. The client then initiates a direct mTLS connection to that endpoint, using its X.509-SVID as its client certificate and verifying the server’s SVID against the federated trust bundle. Because the server uses standard mTLS (without Istio ALPN extensions), an Istio proxy cannot be used on the client side.

Cofide Agent provisions the necessary Istio resources to route traffic via an Istio gateway. The Istio gateway operates in PASSTHROUGH mode: unlike AUTO_PASSTHROUGH, it forwards TCP streams without any SNI-based routing modifications, allowing the client’s standard mTLS handshake to reach the server unchanged.

---
title: SPIFFE-native with Istio Federated Service and xDS Client
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Trust Zone 1]
    group trust_zone_2(cloud)[Trust Zone 2]
    service service_a(server)[Service A] in trust_zone_1
    service spiffe_a(database)[SPIFFE Workload API] in trust_zone_1
    service client_b(server)[Client B] in trust_zone_2
    service spiffe_b(database)[SPIFFE Workload API] in trust_zone_2
    service cofide_agent(server)[Cofide Agent xDS] in trust_zone_2
    service gateway(cloud)[Istio Gateway] in trust_zone_1

    service_a:T --> B:spiffe_a
    client_b:T --> B:spiffe_b
    client_b:R --> L:gateway
    client_b:B --> T:cofide_agent
    gateway:R --> L:service_a

SPIFFE-native with Istio Federated Service and Cofide Proxy Client

Example: ping-pong in cofide-demos, annotated with spiffe.cofide.io/inject=proxy

Both client and server retrieve X.509-SVIDs directly from the SPIFFE workload API and handle their own TLS. Neither is deployed with an Istio proxy. The client uses spiffe-enable to inject a Cofide Proxy sidecar, enabled by annotating the client pod with spiffe.cofide.io/inject=proxy. A Cofide Federated Service exposes the server outside of its cluster and enables discovery from the client’s trust zone.

Unlike the xDS client pattern, the application code requires no changes: iptables rules redirect the client’s outbound traffic to the Cofide Proxy sidecar transparently. The proxy sidecar uses the Cofide Agent xDS API to resolve the federated service hostname to the Istio gateway address, then forwards the client’s mTLS connection to the gateway. The server uses standard mTLS without Istio ALPN extensions, so the client cannot use an Istio proxy sidecar.

Cofide Agent provisions the necessary Istio resources to route traffic via an Istio gateway. The Istio gateway operates in PASSTHROUGH mode, forwarding the client’s mTLS stream to the server without modification.

---
title: SPIFFE-native with Istio Federated Service and Cofide Proxy Client
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Trust Zone 1]
    group trust_zone_2(cloud)[Trust Zone 2]
    group client_pod[Client B pod] in trust_zone_2
    service service_a(server)[Service A] in trust_zone_1
    service spiffe_a(database)[SPIFFE Workload API] in trust_zone_1
    service client_b(server)[Client B] in client_pod
    service proxy_b(cloud)[Cofide Proxy] in client_pod
    service spiffe_b(database)[SPIFFE Workload API] in trust_zone_2
    service cofide_agent(server)[Cofide Agent xDS] in trust_zone_2
    service gateway(cloud)[Istio Gateway] in trust_zone_1

    service_a:T --> B:spiffe_a
    client_b:T --> B:spiffe_b
    client_b:R --> L:proxy_b
    proxy_b:R --> L:gateway
    proxy_b:B --> T:cofide_agent
    gateway:R --> L:service_a

SPIFFE-helper with Istio Federated Service and Cofide Proxy Client

Both client and server use X.509-SVIDs from the filesystem, retrieved and renewed by SPIFFE-helper from the SPIFFE workload API. SPIFFE-helper runs as a sidecar that watches the workload API and writes the SVID, private key, and trust bundle to files on a shared volume, rotating them automatically before expiry. This pattern is useful for applications that cannot use the workload API gRPC socket directly but can load TLS credentials from the filesystem. Neither is deployed with an Istio proxy. The client uses spiffe-enable to inject a Cofide Proxy sidecar. A Cofide Federated Service exposes the server outside of its cluster and enables discovery from the client’s trust zone.

The client’s proxy sidecar uses the Cofide Agent xDS API to discover the service and Istio gateway using the federated service hostname. The client initiates an mTLS connection to the server’s federated service hostname, which is intercepted by the proxy sidecar and routed via the Istio gateway. The server uses standard mTLS without Istio ALPN extensions, so the client cannot use an Istio proxy sidecar.

---
title: SPIFFE-helper with Istio Federated Service and Cofide Proxy Client
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Trust Zone 1]
    group trust_zone_2(cloud)[Trust Zone 2]
    group service_pod[Service A pod] in trust_zone_1
    group client_pod[Client B pod] in trust_zone_2
    service service_a(server)[Service A] in service_pod
    service spiffe_a(database)[SPIFFE Workload API] in trust_zone_1
    service spiffe_helper_a(database)[SPIFFE helper] in service_pod
    service client_b(server)[Client B] in client_pod
    service proxy_b(cloud)[Cofide Proxy] in client_pod
    service spiffe_helper_b(database)[SPIFFE helper] in client_pod
    service spiffe_b(database)[SPIFFE Workload API] in trust_zone_2
    service cofide_agent(server)[Cofide Agent xDS] in trust_zone_2
    service gateway(cloud)[Istio Gateway] in trust_zone_1

    spiffe_helper_a:T --> B:spiffe_a
    service_a:R --> L:spiffe_helper_a
    spiffe_helper_b:T --> B:spiffe_b
    client_b:L --> R:spiffe_helper_b
    client_b:R --> L:proxy_b
    proxy_b:R --> L:gateway
    proxy_b:B --> T:cofide_agent
    gateway:R --> L:service_a

JWT-SVID patterns

SPIFFE-native JWT-SVID in Kubernetes

Example: ping-pong-jwt in cofide-demos

Both client and server retrieve JWT-SVIDs from the SPIFFE workload API.

The client requests a JWT-SVID from the workload API targeting the server’s SPIFFE ID or a well-known audience string agreed upon by both workloads. The client includes its JWT-SVID as a Bearer token in the Authorization header of plain-text HTTP requests to the server. The server validates the client’s JWT-SVID by fetching the JWKS bundle from the workload API and verifying the token’s signature, expiry, and audience claim. The server extracts the client’s SPIFFE ID from the validated token and can use it for authorization decisions. Unlike X.509-SVID patterns, JWT-SVIDs provide application-layer authentication and do not require an end-to-end TLS connection. However, as bearer tokens, they are susceptible to replay attacks when TLS is terminated by middle boxes such as layer 7 proxies.

Traffic is routed via a Kubernetes load balancer service, though an ingress or gateway can be used instead.

---
title: SPIFFE-native JWT in Kubernetes
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Trust Zone 1]
    group trust_zone_2(cloud)[Trust Zone 2]
    service service_a(server)[Service A] in trust_zone_1
    service spiffe_a(database)[SPIFFE Workload API] in trust_zone_1
    service client_b(server)[Client B] in trust_zone_2
    service spiffe_b(database)[SPIFFE Workload API] in trust_zone_2
    service k8s_lb(cloud)[LoadBalancer Service] in trust_zone_1
    service_a:T --> B:spiffe_a
    client_b:T --> B:spiffe_b
    client_b:R --> L:k8s_lb
    k8s_lb:R --> L:service_a

Public Cloud Federation

Example: aws-oidc in cofide-demos

A workload uses its JWT-SVID as an OIDC web identity token to authenticate to a public cloud provider, without any long-lived credentials. In this example, a consumer workload (in the production trust zone) fetches a JWT-SVID from the SPIFFE workload API and presents it to AWS STS via AssumeRoleWithWebIdentity. Cofide Connect acts as the trusted OIDC identity provider, and AWS STS validates the token against the keys in the Connect trust bundle store. On success, STS issues temporary AWS credentials scoped to the IAM role, which the consumer uses to call the AWS S3 API.

An analysis workload (in the analytics trust zone) periodically calls the consumer’s /buckets endpoint. Service-to-service authentication between the two workloads uses mTLS (X.509-SVIDs) or is delegated to Istio.

AWS infrastructure is provisioned via Terraform:

An AWS IAM OIDC provider that trusts the Cofide Connect JWKS endpoint for the trust zone.
An IAM role with an AssumeRoleWithWebIdentity trust policy that matches the consumer workload’s SPIFFE ID and JWT audience

---
title: Public Cloud Federation (JWT-SVID → AWS IAM)
config:
  theme: neo
---
architecture-beta
    group trust_zone_1(cloud)[Production Trust Zone]
    group trust_zone_2(cloud)[Analytics Trust Zone]
    group aws(cloud)[AWS]
    group connect(cloud)[Cofide Connect]
    service consumer(server)[Consumer] in trust_zone_1
    service spiffe_1(database)[SPIFFE Workload API] in trust_zone_1
    service analysis(server)[Analysis] in trust_zone_2
    service spiffe_2(database)[SPIFFE Workload API] in trust_zone_2
    service sts(server)[AWS STS] in aws
    service s3(database)[AWS S3] in aws
    service bundle_store(database)[Trust Bundle Store] in connect

    consumer:T --> B:spiffe_1
    consumer:R --> L:sts
    sts:T --> B:bundle_store
    consumer:B --> L:s3
    analysis:T --> B:spiffe_2
    analysis:R --> L:consumer