Service

Service defines a network service that workloads connect to. Services can be internal (within the infrastructure) or external (third-party APIs, cloud services). Their labels are used by WorkloadIdentity egress selectors and CredentialBinding injection selectors to match outbound traffic to the correct policy and credentials.

• API Group: core.riptides.io
• Version: v1alpha1
• Kind: Service
• Plural: services

Spec

labels

Type	map of string to string
Required	Yes

Labels identify this service for matching by egress selectors in WorkloadIdentity and CredentialBinding resources. When an egress selector specifies {api: openai}, it matches any Service with a labels entry of api: openai.

addresses

Type	array of address objects
Required	No

The network addresses where this service is reachable. Each address entry contains:

Field	Type	Required	Description
address	string	Yes	Hostname, FQDN, or IP address of the service endpoint.
port	integer	No	Port number the service listens on.
tags	array of string	No	Descriptive tags for this address (informational).
aliases	array of string	No	Alternative hostnames or FQDNs that resolve to this address.
networkNames	array of string	No	Network names this address is reachable on.
networkPrefixes	array of string	No	Network CIDR prefixes this address belongs to.

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

external

Type	boolean (nullable)
Required	No

Indicates whether this service is external to the infrastructure.

• true — The service is external (e.g., a third-party API like api.openai.com, a cloud service like s3.amazonaws.com). External services are typically accessed over the public internet and use SIMPLE TLS in egress rules.
• false or omitted — The service is internal (e.g., redis-cart.myapp.svc.cluster.local). Internal services are within the same infrastructure and typically use MUTUAL or PERMISSIVE TLS.

Status

Service resources do not expose a status subresource.

Examples

External service (cloud API)

Define an external API service that workloads connect to with credential injection:

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: openai-svc
  namespace: riptides-system
spec:
  addresses:
    - address: api.openai.com
      port: 443
      tags:
        - openai
        - llm
  external: true
  labels:
    api: openai

External service (AWS)

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: bedrock-runtime
  namespace: riptides-system
spec:
  addresses:
    - address: bedrock-agent-runtime.us-east-1.amazonaws.com
      port: 443
  external: true
  labels:
    app: bedrock-demo
    service: bedrock-agent-runtime

Internal service (Kubernetes)

Define an internal service within the cluster:

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: my-postgres
  namespace: riptides-system
spec:
  addresses:
    - address: postgres-service.myapp.svc.cluster.local
      port: 5432
      tags:
        - postgres
        - database
  external: false
  labels:
    app: postgres

Internal service with multiple addresses

A service reachable on multiple ports through different DNS names:

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: my-elasticsearch
  namespace: riptides-system
spec:
  addresses:
    - address: elasticsearch.myapp.svc.cluster.local
      port: 9200
    - address: elasticsearch.myapp.svc.cluster.local
      port: 9300
  labels:
    app: elasticsearch

How Services Connect to Egress Rules

Services are not referenced by name from WorkloadIdentity or CredentialBinding. Instead, egress selectors match against service labels. This decouples identity policy from specific service definitions.

For example, given the openai-svc Service above with labels: {api: openai}, a CredentialBinding can target it via injection selectors as follows:

# In a CredentialBinding spec:
propagation:
  injection:
    selectors:
      - api: openai    # matches any Service with label api=openai

WorkloadIdentity egress rules can also target services by label for connection policy overrides:

# In a WorkloadIdentity spec:
egress:
  - selectors:
      - api: openai    # matches any Service with label api=openai
    connection:
      tls:
        mode: SIMPLE

This label-based matching allows you to update service addresses or add new endpoints without modifying identity policies.

Related Resources

• WorkloadIdentity — Egress selectors match against service labels.
• CredentialBinding — Injection selectors match against service labels.
• CredentialSource — Provides the credentials injected into service connections.
• API Reference Overview