mTLS Without Service Definitions

No Service resource or egress rule is required for internal mTLS between two Riptides-managed workloads, provided both peers share the same trust domain (CA) and the peers successfully identify each other as Riptides-managed. When those conditions are met, Riptides automatically establishes a full mutual TLS session with zero service-definition overhead.

How It Works

Ordinarily, policy evaluation at connection time checks both whether the connecting workload has a valid identity (selector match) and whether a service rule authorizes the specific destination. Implicit mTLS splits this check into two stages:

1. Identity resolution. The daemon evaluates the connecting workload’s WorkloadIdentity selectors. If a match is found, the workload receives a valid SPIFFE identity, regardless of whether a service rule exists for this connection.

2. Peer confirmation. The peer must be Riptides-managed and share the same trust domain (CA).

3. Certificate cross-check. The SPIFFE SAN in the peer’s X.509 certificate must match the identity the peer announced during connection setup. A mismatch causes the connection to be rejected immediately.

If either peer is not Riptides-managed or does not share the same trust domain (CA), the implicit mTLS conditions are not met and the connection falls back to plain TCP (observed but not intercepted). In those cases an explicit Service resource with egress rules is required.

Minimal Configuration

No Service resource and no egress rules are required. Define a WorkloadIdentity for each workload:

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: service-a
  namespace: riptides-system
spec:
  workloadID: myapp/service-a
  selectors:
    - process:name: service-a
  scope:
    daemonGroup:
      id: riptides/daemongroup/production/workers

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: service-b
  namespace: riptides-system
spec:
  workloadID: myapp/service-b
  selectors:
    - process:name: service-b
  scope:
    daemonGroup:
      id: riptides/daemongroup/production/workers

Once both WorkloadIdentity resources are applied, any connection between service-a and service-b is automatically secured with mTLS. No Service resource, no egress selectors, no allowedSPIFFEIDs lists needed.

Security Characteristics

• STRICT mTLS always. Both sides must present a valid X.509 SVID issued by the shared trust domain. There is no plaintext fallback once implicit mTLS is active.

• Top-level allowedSPIFFEIDs are enforced. If the WorkloadIdentity defines top-level allowedSPIFFEIDs (outbound on the client side, inbound on the server side), those restrictions apply even for implicit mTLS connections. Per-egress and per-ingress allowedSPIFFEIDs defined inside a Service do not apply — no service rule exists to select them.

• Identity confirmed via two channels. The identity the peer announces during connection setup and the SPIFFE SAN in the TLS certificate must agree. A peer that announces one identity but presents a certificate for a different workload is rejected before any application data is exchanged.

• Only top-level workload identity is evaluated. When no service rule exists, only the selector match that establishes the workload’s identity is considered. Egress label selectors, credential rules, and service-level allowedSPIFFEIDs defined inside a Service are not in scope — those apply only to explicitly configured connections.

When to Use Explicit Service Definitions Instead

Implicit mTLS is the right default for trusted internal mesh traffic where any enrolled peer is acceptable. Use an explicit Service resource with egress rules when you need:

• Per-destination caller restrictions — allowedSPIFFEIDs on an egress or ingress rule limits connections to specific identities for a particular destination. Top-level allowedSPIFFEIDs on a WorkloadIdentity are enforced for implicit mTLS connections too, but they apply globally, not per-destination.
• Credential injection — HTTP headers, AWS SigV4 signing, JWT credentials, or other credentials are attached per destination.
• External services — Connections to endpoints that are not Riptides-managed (cloud APIs, third-party services, legacy systems).
• Per-destination TLS mode — PERMISSIVE or SIMPLE mode on a specific destination, for example during a migration.

Comparison

	Implicit mTLS	Explicit Service + Egress
Required config	WorkloadIdentity only	WorkloadIdentity + Service + egress rules
TLS mode	Always STRICT	Configurable (MUTUAL / PERMISSIVE / SIMPLE)
Caller restrictions	Top-level allowedSPIFFEIDs only	Top-level + per-egress/ingress allowedSPIFFEIDs
Credential injection	Not supported	Supported
External destinations	Not applicable	Supported
Best for	Internal mesh between enrolled workloads	Fine-grained access control, credentials, external services