# Service-से-Service Authorisation — API Gateway और Service Mesh

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

> पहचान-आधारित नीति से सिर्फ़ उन्हीं callers को अनुमति दें जिन्हें मिलनी चाहिए।

## Services के बीच डिफ़ॉल्ट deny

समतल network में हर service हर दूसरी को बुला सकती है, इसलिए एक compromised pod सब तक पहुँच सकता है। mTLS पहचानों से आप **services के बीच least privilege** लागू कर सकते हैं: डिफ़ॉल्ट रूप से सारी calls deny करें, फिर विशिष्ट callers को विशिष्ट ऑपरेशनों की अनुमति दें (जैसे सिर्फ़ `billing` `payments` service पर `POST /payments` कर सकती है)। नीतियाँ end-user संदर्भ के लिए JWT claims भी जाँच सकती हैं। असली call graph सीखने को ढीले, **सिर्फ़-निरीक्षण** mode से शुरू करें, फिर namespace दर namespace प्रवर्तन कसें। Network policies (layer 3/4) उस traffic को रोककर पूरक बनती हैं जो होना ही नहीं चाहिए।

## Service पहचान से allow नियम (Istio, उदाहरण)

सिर्फ़ `billing` service account के रूप में चल रहा workload `POST /payments` बुला सकता है; ALLOW नीति मौजूद होने पर इस workload तक बाक़ी सब deny है। यहाँ चलाया नहीं गया।

```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"] }
```

## Enforce करने से पहले denies log करें

पहले नीति को audit/dry-run mode में चालू करें और देखें कि क्या रोका जाता। वरना छूटा हुआ वैध caller production outage बन जाता है।

**Quiz:** Services के बीच "default deny" का क्या मतलब है?

- [x] Calls तब तक रोकी जाती हैं जब तक कोई नीति स्पष्ट अनुमति न दे
- [ ] सभी calls हमेशा अनुमत हैं
- [ ] Calls सिर्फ़ log होती हैं
- [ ] सिर्फ़ HTTP/1.0 चलता है

*Answer:* Calls तब तक रोकी जाती हैं जब तक कोई नीति स्पष्ट अनुमति न दे. स्पष्ट allow-lists घटाती हैं कि compromised service क्या छू सकती है।