Services

A Service in Riptides represents a network endpoint that workloads connect to. Services define the destinations in your infrastructure — both internal services secured by Riptides and external APIs that workloads need to reach.

What Services Represent

Services are the “other side” of a workload connection. When you define connection policies on a WorkloadIdentity (egress rules), you reference services to specify which destinations a workload is allowed to reach. Services decouple connection policy from network addresses: you define intent (this workload connects to the payment API) rather than infrastructure details (this workload connects to 10.0.3.42:443).

Internal vs External Services

Internal Services

Internal services represent endpoints within your infrastructure that are also managed by Riptides. Connections between workloads and internal services can be secured with mutual TLS, with both sides presenting SPIFFE identities. Access control policies can restrict connections based on the SPIFFE IDs of the connecting workload.

An internal service might represent a database, a message broker, or another microservice running in the same or a different cluster.

External Services

External services represent endpoints outside your infrastructure or outside Riptides management. These include cloud provider APIs (such as AWS S3 or GCP Cloud Storage), third-party SaaS APIs, or legacy systems that do not participate in the SPIFFE trust domain.

For external services, Riptides can inject credentials into outbound connections, apply TLS policies, and enforce which workloads are allowed to connect.

Service Definition

A Service resource specifies the endpoint address, port, protocol, and metadata used for policy matching:

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: payment-api
  namespace: riptides-system
spec:
  addresses:
    - address: payment-api.internal.example.com
      port: 443
  labels:
    team: payments
    tier: backend

Addresses

The addresses field specifies how the service is reached. Each entry is an object with:

• address — A DNS hostname (api.example.com), IP address (10.0.3.42), or FQDN.
• port — The port number the service listens on.
• tags — Optional descriptive tags (informational only).

A service can have multiple address entries, for example when it is reachable on different ports or through different DNS names.

Labels and Policy Matching

Services use labels for categorization and policy matching. WorkloadIdentity egress rules reference services by label selectors rather than by name, enabling flexible grouping.

For example, a WorkloadIdentity might allow egress to all services labeled tier: backend:

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: frontend
  namespace: riptides-system
spec:
  workloadID: myapp/frontend
  selectors:
    - k8s:label:app: frontend
  egress:
    - selectors:
        - tier: backend
      connection:
        tls:
          mode: MUTUAL

This approach means you can add new backend services without updating every workload policy that needs access to them. Apply the tier: backend label to the new service, and existing policies automatically include it.

Tags

Tags provide additional categorization metadata on services. While labels are used for policy selector matching, tags serve organizational purposes such as filtering, reporting, and documentation.

Examples

External Cloud API

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: aws-s3
  namespace: riptides-system
spec:
  addresses:
    - address: s3.us-east-1.amazonaws.com
      port: 443
  external: true
  labels:
    provider: aws
    type: storage

Internal Database

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: orders-db
  namespace: riptides-system
spec:
  addresses:
    - address: orders-db.internal.example.com
      port: 5432
  labels:
    tier: backend
    type: database