Mutual TLS और Workload Identity

दोनों पक्ष certificate दिखाते हैं

सामान्य TLS में सिर्फ़ server अपनी पहचान साबित करता है। Mutual TLS (mTLS) में client भी ऐसा certificate दिखाता है जो दोनों पक्षों के भरोसेमंद CA ने हस्ताक्षरित किया है, इसलिए हर पक्ष जानता है कि दूसरी ओर कौन है और traffic encrypted है। Mesh कठिन हिस्से स्वचालित करता है: उसका control plane CA की तरह काम करता है, हर workload को उसकी पहचान से बँधा अल्पकालिक certificate देता है (जैसे SPIFFE-शैली नाम में Kubernetes service account), उसे अपने आप बदलता है और sidecars handshake करते हैं, इसलिए applications स्थानीय रूप से सादा HTTP बोलते रहते हैं। mTLS से आप "सिर्फ़ billing service orders को बुला सकती है" जैसी नीति लिख सकते हैं और network स्थान पर निर्भर नहीं रहते, जो zero trust का एक निर्माण-खंड है।

पहचान, नीति, telemetry

Mesh हर service को क्रिप्टोग्राफ़िक पहचान देता है, traffic नीति लागू करता है और जो होता है उसे दर्ज करता है।

openssl से असली mutual-TLS handshake

यह script (OpenSSL 3.0.13) निजी CA, orders.mesh.local के लिए server certificate और billing.mesh.local के लिए client certificate बनाती है, फिर ऐसा server शुरू करती है जो client certificate माँगता है। सिर्फ़ demo के लिए keys, 30 दिन वैध।

# 1. a private CA, a server certificate and a client certificate (all demo-only, 30 days)
openssl req -x509 -newkey rsa:2048 -nodes -keyout ca.key -out ca.crt -days 30 -subj "/CN=demo-mesh-ca"
mk() { openssl req -newkey rsa:2048 -nodes -keyout $1.key -out $1.csr -subj "/CN=$2"
       printf "subjectAltName=DNS:$2\n" > $1.ext
       openssl x509 -req -in $1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out $1.crt -days 30 -extfile $1.ext; }
mk server orders.mesh.local
mk client billing.mesh.local

# 2. a server that REQUIRES a client certificate signed by our CA
openssl s_server -accept 4433 -cert server.crt -key server.key -CAfile ca.crt -Verify 1 -verify_return_error -www &

# 3a. client WITH its certificate
echo "GET /" | openssl s_client -connect 127.0.0.1:4433 -servername orders.mesh.local \
   -CAfile ca.crt -cert client.crt -key client.key -verify_hostname orders.mesh.local

# 3b. client WITHOUT a certificate
echo "GET /" | openssl s_client -connect 127.0.0.1:4433 -servername orders.mesh.local -CAfile ca.crt

Handshakes ने क्या दिखाया, चलाकर

मैंने script चलाई और मुख्य पंक्तियाँ छानीं। वैध client certificate के साथ handshake TLS 1.3 पर सफल होता है और chain CA के विरुद्ध सत्यापित होती है (Verification: OK, Verify return code: 0)। Client certificate के बिना, server TLS alert certificate required के साथ connection अस्वीकार करता है।

with client cert:
  subject=CN = orders.mesh.local
  issuer=CN = demo-mesh-ca
  Verification: OK
  New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
  Verify return code: 0 (ok)

without client cert:
  ...ssl3_read_bytes:tlsv13 alert certificate required...SSL alert number 116

अल्पकालिक certificates, revocation से बेहतर

जो certificates घंटों जीते हैं और अपने आप नवीनीकृत होते हैं, वे चुराई गई key को जल्दी बेकार कर देते हैं और revocation सूचियों की परेशानी से बचाते हैं। बड़े पैमाने पर हाथ से certificate प्रबंधन ठीक वही काम है जो meshes हटाते हैं।

त्वरित जाँच: सामान्य TLS की तुलना में mTLS क्या जोड़ता है?

• यह traffic सार्वजनिक करता है
• यह encryption हटाता है
• Client भी certificate से अपनी पहचान साबित करता है
• यह DNS की जगह लेता है