Unified Security Hardening Workflow: Integrating OPA with Istio for Token‑Bucket Rate Limiting on OpenClaw Rating API

2. Overview of OpenClaw Rating API

The OpenClaw Rating API is a RESTful service that:

• Accepts POST /ratings payloads from client applications.
• Validates user tokens against an OAuth2 provider.
• Persists rating data in a PostgreSQL store.
• Exposes GET /ratings/{itemId} for aggregated score retrieval.

Because the endpoint is publicly reachable, it is a prime target for:

• Credential stuffing attacks.
• Burst traffic spikes that can overwhelm the database.
• Malicious bots attempting to skew rating metrics.

3. Security challenges

The most common threats to the Rating API include:

Traditional network firewalls cannot differentiate between legitimate and malicious API calls once traffic reaches the service mesh. Therefore, a service‑mesh‑aware policy engine is required.

4. Introducing OPA and Istio sidecar

Open Policy Agent (OPA) is a lightweight, general‑purpose policy engine that evaluates JSON‑based policies written in Rego. When paired with Istio, OPA can be deployed as an Envoy sidecar that intercepts inbound/outbound traffic and enforces decisions in real time.

Key benefits:

• Centralized policy management across all services.
• Fine‑grained control (per‑method, per‑user, per‑IP).
• Zero‑code integration – policies live outside the application codebase.

UBOS makes it trivial to spin up an UBOS platform overview that includes Istio and OPA as first‑class citizens. The Workflow automation studio can further automate policy deployment pipelines.

5. Token‑bucket rate limiting concept

The token‑bucket algorithm is a classic traffic‑shaping technique. It works by:

1. Refilling a bucket with r tokens per second (the refill rate).
2. Allowing a request to proceed only if the bucket contains at least one token.
3. Consuming one token per successful request.

This model supports short bursts (when the bucket is full) while guaranteeing a long‑term average rate. In the context of the Rating API, we can enforce:

• Maximum 5 requests per second per authenticated user token.
• Global ceiling of 200 requests per second for the entire service.

OPA’s Rego language can express this logic, and Istio’s Envoy filter can call OPA for each inbound request.

6. Step‑by‑step integration guide

6.1 Prerequisites

• UBOS cluster with Enterprise AI platform by UBOS enabled.
• Kubectl access to the cluster.
• Helm 3.x installed locally.
• Basic knowledge of Rego syntax.

6.2 Deploy Istio with OPA sidecar

Run the following Helm command to install Istio and the OPA sidecar injector:

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

helm install istio-base istio/base -n istio-system --create-namespace
helm install istiod istio/istiod -n istio-system --wait

# OPA sidecar injector
helm install opa-gatekeeper \
  gatekeeper/gatekeeper \
  -n opa-system --create-namespace \
  --set enableExternalData=true

6.3 Create the Rego policy

Save the following policy as rating_rate_limit.rego and push it to your GitOps repo.

package istio.authz

default allow = false

# Global token bucket (200 rps)
global_bucket = {
    "capacity": 200,
    "refill_rate": 200,
    "tokens": 200,
    "last_refill": time.now_ns()
}

# Per‑user bucket (5 rps)
user_bucket[user] = {
    "capacity": 5,
    "refill_rate": 5,
    "tokens": 5,
    "last_refill": time.now_ns()
} {
    input.method == "POST"
    input.path == ["ratings"]
    token := input.request.headers["authorization"][0]
    user := split(token, " ")[1]  # assume Bearer 
}

allow {
    # Verify JWT (simplified)
    token := input.request.headers["authorization"][0]
    startswith(token, "Bearer ")
    # Rate‑limit check
    bucket := user_bucket[user]
    refreshed := refresh(bucket)
    refreshed.tokens > 0
}

refresh(bucket) = new_bucket {
    now := time.now_ns()
    elapsed := (now - bucket.last_refill) / 1e9
    added := elapsed * bucket.refill_rate
    new_tokens := min(bucket.capacity, bucket.tokens + added)
    new_bucket := {
        "capacity": bucket.capacity,
        "refill_rate": bucket.refill_rate,
        "tokens": new_tokens - 1,   # consume one token
        "last_refill": now,
    }
}

6.4 Package the policy as a ConfigMap

kubectl create configmap rating-rate-limit \
  --from-file=rating_rate_limit.rego \
  -n opa-system

6.5 Attach the policy to the Rating service

Add an EnvoyFilter that forwards authorization requests to OPA.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: rating-opa-authz
  namespace: default
spec:
  workloadSelector:
    labels:
      app: openclaw-rating
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          portNumber: 80
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.ext_authz
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
            http_service:
              server_uri:
                uri: opa.opa-system.svc.cluster.local
                cluster: outbound|8181||opa.opa-system.svc.cluster.local
                timeout: 0.5s
              authorization_request:
                allowed_headers:
                  patterns:
                    - exact: ":method"
                    - exact: ":path"
                    - exact: "authorization"
              authorization_response:
                allowed_upstream_headers:
                  patterns:
                    - exact: "x-allowed"

6.6 Deploy the Rating API with sidecar injection

apiVersion: apps/v1
kind: Deployment
metadata:
  name: openclaw-rating
  labels:
    app: openclaw-rating
spec:
  replicas: 3
  selector:
    matchLabels:
      app: openclaw-rating
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
      labels:
        app: openclaw-rating
    spec:
      containers:
        - name: rating-api
          image: ubos/openclaw-rating:latest
          ports:
            - containerPort: 80

6.7 Verify OPA policy is active

Run a quick curl test from a pod inside the mesh:

TOKEN=$(curl -s -X POST https://auth.example.com/token -d "client_id=xyz&client_secret=abc")
for i in {1..7}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -H "Authorization: Bearer $TOKEN" \
    http://openclaw-rating.default.svc.cluster.local/ratings
done

The first five requests should return 200, while the sixth and seventh should return 429 Too Many Requests, confirming the per‑user token bucket is enforced.

7. Testing and verification

A robust CI pipeline should include:

1. Unit tests for Rego policies using opa test.
2. Integration tests that spin up a temporary mesh (e.g., using kind) and run the curl loop above.
3. Load testing with Locust or k6 to simulate 500 concurrent users and verify the global bucket never exceeds 200 RPS.

7.1 Sample OPA unit test

package istio.authz_test

test_allow_when_under_limit {
  input := {
    "method": "POST",
    "path": ["ratings"],
    "request": {
      "headers": {
        "authorization": ["Bearer test-token"]
      }
    }
  }
  allow with input as input
}

7.2 Monitoring

Export OPA decision metrics to Prometheus and create Grafana dashboards that show:

• Requests allowed vs. denied per minute.
• Current token count per user (debug view).
• Latency introduced by the sidecar (should stay < 5 ms).