Service-से-Service Authorisation

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 है। यहाँ चलाया नहीं गया।

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 बन जाता है।

त्वरित जाँच: Services के बीच "default deny" का क्या मतलब है?

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