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, wildcard FQDN (*.example.com), or IP address of the service endpoint.
port	integer	No	Port number the service listens on.
aliases	array of string	No	Alternative hostnames or FQDNs that resolve to this address.
networkPrefixes	array of string	No	Explicit CIDR ranges (e.g. 10.0.0.0/16) that this address’s network resolves to.
networkNames	array of string	No	Symbolic, provider-backed names (see Known network names) that the daemon resolves to that provider’s published IP ranges at runtime.

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

Wildcard addresses

A wildcard address (e.g. *.s3.amazonaws.com) is not directly resolvable to a concrete IP, so it cannot be enforced from DNS lookups alone. Any such address must also set networkPrefixes or networkNames, so the daemon knows the concrete network range the wildcard covers. This is validated at admission time: a wildcard address without one of these fields is rejected.

The only exception is a small set of well-known provider wildcards, including *.amazonaws.com, *.amazonaws.cn, *.amazonaws.com.cn, and *.googleapis.com, which are recognized automatically and don’t require networkPrefixes or networkNames.

Known network names

Each entry in networkNames is either just a provider name (matching every published IP range for that provider) or <provider>:<type> (matching only the named type within that provider). Ranges are kept up to date automatically by the daemon.

Provider	Types	Notes
aws	Per-service, e.g. s3, ec2, cloudfront, route53, dynamodb	Sourced from AWS’s published ip-ranges.json. The full set of service names is defined by AWS and changes over time; aws alone matches every AWS service.
azure	Per service tag, e.g. storage, sql, app_service	Sourced from Azure’s published Service Tags file. Tag names are defined by Azure (converted to snake_case); azure alone matches every tag.
google	service	Google’s own service IP ranges (Search, Gmail, etc.), from goog.json.
google-cloud	cloud	Google Cloud Platform customer-facing IP ranges, from cloud.json.
github	hooks, web, api, git, github_enterprise_importer, packages, pages, importer, actions, actions_macos, codespaces, copilot	Sourced from GitHub’s published meta API.

For example, networkNames: [aws:s3] matches only S3’s IP ranges, while networkNames: [aws] matches every AWS service’s ranges.

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
  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
  external: false
  labels:
    app: postgres

External service with a wildcard address

*.s3.amazonaws.com isn’t one of the automatically recognized provider wildcards, so networkNames must be set to tell the daemon which provider’s IP ranges to enforce against:

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

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