# Service-to-Service Authorisation — API Gateway and Service Mesh

Source: https://www.geekswithgeeks.com/en/api-gateway-service-mesh/m-authz-policy

> Allow only the callers that should be allowed using identity-based policy.

## Default deny between services

Inside a flat network every service can call every other, so one compromised pod can reach everything. With mTLS identities you can enforce **least privilege between services**: deny all calls by default, then allow specific callers to specific operations (for example, only `billing` may `POST /payments` on the `payments` service). Policies can also check JWT claims for end-user context. Start in a permissive, **observe-only** mode to learn the real call graph, then tighten to enforcement namespace by namespace. Network policies (layer 3/4) complement this by blocking traffic that should not exist at all.

## An allow rule by service identity (Istio, illustrative)

Only the workload running as the `billing` service account may call `POST /payments`; anything else to this workload is denied once an ALLOW policy exists. Not run here.

```yaml
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: { name: payments-allow-billing, namespace: shop }
spec:
  selector: { matchLabels: { app: payments } }
  action: ALLOW
  rules:
    - from:
        - source: { principals: ["cluster.local/ns/shop/sa/billing"] }
      to:
        - operation: { methods: ["POST"], paths: ["/payments"] }
```

## Log denies before you enforce

Turn on policy in audit/dry-run mode first and review what would be blocked. Otherwise a missed legitimate caller turns into a production outage.

**Quiz:** What does "default deny" between services mean?

- [x] Calls are blocked unless a policy explicitly allows them
- [ ] All calls are always allowed
- [ ] Calls are logged only
- [ ] Only HTTP/1.0 works

*Answer:* Calls are blocked unless a policy explicitly allows them. Explicit allow-lists reduce what a compromised service can reach.