Sonu\u00e7ta hi\u00e7 birimiz hassas verilerimizin kolayl\u0131kla ele ge\u00e7irilebilmesini istemeyiz, de\u011fil mi?<\/p>\n
Bu makale kapsam\u0131nda ise “microservice’ler aras\u0131 ileti\u015fimi, Istio<\/a> Service Mesh<\/strong> ile nas\u0131l g\u00fcvenli bir hale getirebiliriz” konusuna de\u011finmeye \u00e7al\u0131\u015faca\u011f\u0131m.<\/p>\n Bildi\u011fimiz gibi microservice ekosistemi i\u00e7erisinde istio gibi bir service mesh teknolojisi kulland\u0131\u011f\u0131m\u0131zda, uygulamalar\u0131m\u0131z aras\u0131 ileti\u015fimi service mesh do\u011fas\u0131 gere\u011fi ele almaktad\u0131r.<\/p>\n B\u00f6ylece uygulama taraf\u0131nda herhangi bir kod de\u011fi\u015fikli\u011fi yapmadan reliability<\/strong>, discovery<\/strong> ve monitoring<\/strong> gibi alanlarda istio’dan yararlanabilmekteyiz. Bunlar\u0131n yan\u0131 s\u0131ra microservice’ler aras\u0131 g\u00fcvenli ileti\u015fimi sa\u011flayabilmemiz i\u00e7in de bizlere farkl\u0131 \u00e7\u00f6z\u00fcmler sunmaktad\u0131r.<\/p>\n Microservice’lerimiz her ne kadar g\u00fcvenli<\/strong> olarak kabul etti\u011fimiz internal ortamlar\u0131m\u0131zda \u00e7al\u0131\u015f\u0131yor olsa da, microservice’ler aras\u0131 ileti\u015fimi encrypted bir hale getirmek g\u00fcvenlik a\u00e7\u0131s\u0131ndan her t\u00fcrl\u00fc avantaj\u0131m\u0131za olacakt\u0131r.<\/p>\n G\u00fcvenlik kapsam\u0131nda istio, iki farkl\u0131 authentication y\u00f6ntemini desteklemektedir.<\/p>\n Az \u00f6nce de bahsetti\u011fimiz gibi, kod taraf\u0131nda herhangi bir de\u011fi\u015fiklik yapmadan microservice’ler aras\u0131 g\u00fcvenli ileti\u015fimi istio ile sa\u011flayabilmekteyiz. Istio proxy, herhangi bir sertifikay\u0131 y\u00f6netmemize gerek kalmadan, 443<\/strong> port’u \u00fczerindeki trafi\u011fi bizim i\u00e7in y\u00f6netip, uygulama’n\u0131n 80<\/strong> port’una y\u00f6nlendirmektedir.<\/p>\n Istio bu tarz i\u015flemler ve network’\u00fc intercept edebilmek i\u00e7in, a\u015fa\u011f\u0131daki diyagramdan da g\u00f6rebilece\u011fimiz gibi Envoy<\/a>‘un sidecar proxy’sini kullanmaktad\u0131r.<\/p>\n Bu ak\u0131\u015f\u0131 ise kabaca \u00f6zetlemek gerekirse;<\/strong><\/p>\n E\u011fer bu do\u011frulama i\u015flem ba\u015far\u0131l\u0131 ger\u00e7ekle\u015firse, client’\u0131n sidecar’\u0131 bu trafi\u011fi encpyt eder ve server’\u0131n sidecar’\u0131na g\u00f6nderir. Server sidecar’\u0131 ise bu trafi\u011fi decrypt ederek, trafi\u011fi gitmesi gereken noktaya y\u00f6nlendirir.<\/p>\n Ek olarak istio, sertifikalar\u0131n olu\u015fturulmas\u0131 ve y\u00f6netilmesi i\u015flemini de bizler i\u00e7in p\u00fcr\u00fczs\u00fcz bir \u015fekilde ger\u00e7ekle\u015ftirmektedir. B\u00f6ylece operasyonel y\u00fcklerimizi de azalmaya yard\u0131mc\u0131 olmaktad\u0131r.<\/p>\n \u00d6rnek ger\u00e7ekle\u015ftirebilmemiz i\u00e7in .NET Core ile \u00fcr\u00fcn ve stok bilgilerini d\u00f6nen basit birka\u00e7 API geli\u015ftirdim. \u0130lk olarak geli\u015ftirmi\u015f oldu\u011fum\u00a0“Product<\/em>“, “Stock<\/em>” ve “Product Gateway<\/em>” API’lar\u0131n\u0131 kubernetes cluster’\u0131na deploy edece\u011fiz. Ard\u0131ndan istio mesh ile bu\u00a0API’lar aras\u0131nda ger\u00e7ekle\u015fecek olan ileti\u015fimi mTLS<\/strong> ile g\u00fcvenli bir hale getirece\u011fiz.<\/p>\n \u00d6rne\u011fimizde “Product Gateway<\/em>” API’\u0131n\u0131n, GET “\/products\/1<\/em>” endpoint’ini kullanaca\u011f\u0131z. Bu endpoint k\u0131saca a\u015fa\u011f\u0131daki logic’i i\u00e7ermektedir ve basit olarak bir \u00fcr\u00fcn response’u d\u00f6nmektedir.<\/p>\n \u00d6rnek kodlara ise buradan<\/a><\/em> ula\u015fabilirsiniz.<\/p>\n Uygulamalar\u0131 deploy etmeye ba\u015flamadan \u00f6nce, istio sevice mesh’i kubernetes cluster’\u0131na kurmam\u0131z gerekmektedir.<\/p>\n Farkl\u0131 platform’lara g\u00f6re kurulum i\u015flemlerini buradaki<\/a><\/em> ad\u0131mlar\u0131 takip ederek ger\u00e7ekle\u015ftirebilirsiniz. Ben bu makale kapsam\u0131nda Docker Desktop ve Istio 1.7.3<\/strong>\u00a0kullanaca\u011f\u0131m.<\/p>\n Ba\u015far\u0131l\u0131 bir kurulum i\u015fleminden sonra da, a\u015fa\u011f\u0131daki gibi bir sonu\u00e7 g\u00f6r\u00fcyor olmal\u0131y\u0131z.<\/p>\n Son olarak otomatik sidecar injection i\u015flemini ger\u00e7ekle\u015ftirebilmemiz i\u00e7in, istedi\u011fimiz bir namespace’e a\u015fa\u011f\u0131daki gibi bir label eklememiz gerekmektedir.<\/p>\n Ben burada “default” namespace’ini kullanaca\u011f\u0131m. B\u00f6ylece bu namespace alt\u0131nda konumlanacak olan uygulamalar, otomatik olarak mesh i\u00e7erisine dahil olacaklard\u0131r.<\/p>\n \u015eimdi \u00f6rnek API’lar\u0131n deployment i\u015flemlerine ba\u015flayabiliriz.<\/p>\n Ilk olarak image’leri a\u015fa\u011f\u0131daki komut yard\u0131m\u0131yla olu\u015ftural\u0131m.<\/p>\n Ard\u0131ndan burada<\/em> haz\u0131rlam\u0131\u015f oldu\u011fum “deploy.yaml” dosyas\u0131n\u0131 kullanarak, a\u015fa\u011f\u0131daki gibi deployment i\u015flemlerini tamamlayal\u0131m.<\/p>\n Deployment i\u015flemleri ba\u015far\u0131yla tamamland\u0131ktan sonra ise, pod’lar\u0131n sidecar’lar\u0131 ile beraber 2\/2<\/strong> “Running” stat\u00fcs\u00fcne ge\u00e7ene kadar bekleyelim.<\/p>\n Ayr\u0131ca a\u015fa\u011f\u0131daki komut yard\u0131m\u0131yla ilgili pod’un mesh i\u00e7erisine dahil olup olmad\u0131\u011f\u0131n\u0131 da kontrol edebiliriz.<\/p>\n API’lar\u0131n sorunsuz bir \u015fekilde \u00e7al\u0131\u015ft\u0131klar\u0131n\u0131 test edebilmek i\u00e7in ise, herhangi bir pod \u00fczerinden a\u015fa\u011f\u0131daki gibi “Product Gateway<\/em>” API’\u0131n “\/products\/1<\/em>” endpoint’ine bir GET iste\u011finde bulunal\u0131m.<\/p>\n Yukar\u0131daki resimden de g\u00f6rebilece\u011fimiz gibi, “Product<\/em> Gateway<\/em>” API’\u0131na\u00a0HTTP \u00fczerinden ba\u015far\u0131yla eri\u015febildik ve \u00fcr\u00fcn bilgisi sonucunu alabildik.<\/p>\n API’lar problemsiz \u00e7al\u0131\u015ft\u0131\u011f\u0131na g\u00f6re \u015fimdi bu ileti\u015fimi end-to-end olarak mTLS<\/strong> ile g\u00fcvenli bir hale getirebiliriz.<\/p>\n Genel olarak, az \u00f6nce HTTP \u00fczerinden ger\u00e7ekle\u015ftirmi\u015f oldu\u011fumuz i\u015flemi de g\u00fcvenli olarak kabul edebiliriz. \u00c7\u00fcnk\u00fc istio, 1.5 versiyonundan bu yana auto mTLS<\/strong> \u00f6zelli\u011fi etkin<\/strong> ve permissive<\/strong> mode olarak gelmektedir.<\/p>\n Peki bunu nas\u0131l \u00f6zelle\u015ftirebiliriz? Haydi biraz daha detaya girelim.<\/p>\n Istio i\u00e7erisinde mTLS seviyelerini uygulayabilece\u011fimiz \u00fc\u00e7 farkl\u0131 nokta bulunmaktad\u0131r.<\/p>\n Bu seviyeler en k\u00fc\u00e7\u00fc\u011fe do\u011fru birbirlerini override ederek gitmektedir. \u00d6rne\u011fin farkl\u0131 namespace’ler alt\u0131nda veya ayn\u0131 namespace’de farkl\u0131 gereksinimlere ihtiya\u00e7 duyan uygulamalar\u0131m\u0131z olabilir. K\u0131sacas\u0131 gereksinimlerimiz do\u011frultusunda diledi\u011fimiz seviyede mTLS i\u015flemlerini ger\u00e7ekle\u015ftirebiliriz. Bu konu hakk\u0131ndaki detayl\u0131 bilgiye ise buradan<\/a><\/em> eri\u015febilirsiniz.<\/p>\n Ben “default” namespace’i kapsam\u0131nda mTLS’i a\u015fa\u011f\u0131daki gibi \u00f6zelle\u015ftirerek etkinle\u015ftirece\u011fim. Bu i\u015flemden beklentimiz ise, uygulamalar\u0131m\u0131z \u00fczerinde herhangi bir de\u011fi\u015fiklik yapmadan uygulamalar\u0131m\u0131z\u0131n “default” namespace’i alt\u0131nda sadece<\/strong> mTLS trafi\u011fini kabul etmelerini sa\u011flamak olacak.<\/p>\n Bu i\u015flemi yapabilmek i\u00e7in ise a\u015fa\u011f\u0131daki gibi istio’nun “PeerAuthentication<\/em>” custom resource’unu kullanaca\u011f\u0131z.<\/p>\n Mutual TLS’i “default” namespace’i kapsam\u0131nda etkinle\u015ftirece\u011fimiz i\u00e7in, “metadata<\/em>” alt\u0131nda bulunan “namespace<\/em>” element’inin de\u011ferini “default<\/em>” olarak set etmemiz gerekmektedir.<\/p>\n Ayr\u0131ca STRICT<\/strong>, PERMISSIVE<\/strong>\u00a0ve DISABLED <\/strong>olmak \u00fczere \u00fc\u00e7 farkl\u0131 kullanabilece\u011fimiz mTLS mode’u bulunmaktad\u0131r. Auto mTLS \u00f6zelli\u011finin ise default olarak permissive mode’da geldi\u011finden bahsetmi\u015ftik. Biz \u00f6rnek gere\u011fi mTLS’i zorunlu k\u0131laca\u011f\u0131m\u0131z i\u00e7in, “STRICT<\/em>” olan modu kullanaca\u011f\u0131z.<\/p>\n Encrypted trafi\u011fin yan\u0131nda plain-text<\/strong> trafi\u011fe de izin vermek istiyorsak, “PERMISSIVE<\/em>” modu’u da kullanabiliriz. \u00c7\u00fcnk\u00fc kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck problemlerden birisi, hen\u00fcz service mesh ekosistemine adapte olmam\u0131\u015f uygulamalar i\u00e7in trafi\u011fi kesmek ve bu s\u00fcreci daha karma\u015f\u0131k bir hale getirmektedir. \u00d6zellikle sizde bizim gibi hem Windows<\/strong> hem de Linux<\/strong> container’lar ile \u00e7al\u0131\u015f\u0131yorsan\u0131z, kar\u015f\u0131la\u015f\u0131lmas\u0131 ka\u00e7\u0131n\u0131lmaz bir durum haline geliyor.<\/p>\n K\u0131sacas\u0131 “PERMISSIVE<\/em>” modu’u kullanarak, sistem i\u00e7erisine yeni migrate olmaya \u00e7al\u0131\u015fan uygulamalar\u0131n, bu migration s\u00fcre\u00e7lerini daha p\u00fcr\u00fczs\u00fcz bir hale getirebiliriz.<\/p><\/blockquote>\n Bunlar\u0131n yan\u0131 s\u0131ra mTLS’i a\u015fa\u011f\u0131daki gibi port seviyesinde de \u00f6zelle\u015ftirebilmek m\u00fcmk\u00fcnd\u00fcr.<\/p>\n Peki, mTLS’i zorunlu k\u0131lmak istedi\u011fimiz i\u00e7in yukar\u0131daki yaml<\/em> dosyas\u0131n\u0131 kubernetes \u00fczerinde a\u015fa\u011f\u0131daki gibi apply edelim.<\/p>\n \u015eimdi uygulam\u0131\u015f oldu\u011fumuz mTLS zorunlulu\u011funun ge\u00e7erli olup olmad\u0131\u011f\u0131n\u0131 test edelim. Bunun i\u00e7in mesh i\u00e7erisine dahil olmayan bir test pod’una ihtiyac\u0131m\u0131z var.<\/p>\n Test i\u015flemini ger\u00e7ekle\u015ftirebilmek i\u00e7in ise a\u015fa\u011f\u0131daki gibi “test” namespace’i alt\u0131nda istio taraf\u0131ndan y\u00f6netilmeyecek olan bir test pod’u olu\u015ftural\u0131m ve ard\u0131ndan “Product Gateway<\/em>” API’\u0131na tekrardan HTTP \u00fczerinden bir istek atmaya \u00e7al\u0131\u015fal\u0131m.<\/p>\n G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi bu sefer “Product Gateway<\/em>” API’\u0131na HTTP \u00fczerinden eri\u015femedik. \u00c7\u00fcnk\u00fc “default” namespace’i alt\u0131nda bulunan uygulamalar\u0131m\u0131z, art\u0131k sadece mTLS trafi\u011fini kabul etmektedirler.<\/p>\n Wohho! Uygulamalar\u0131m\u0131z art\u0131k bir t\u0131k daha fazla g\u00fcvenli durumda.<\/p>\n \u00c7ok fazla detaya girmeden k\u0131saca inceleyelim.<\/p>\n Bu i\u015flemleri daha net anlayabilmemiz i\u00e7in, envoy proxy’nin “Listener” ve “Cluster” configuration’lar\u0131n\u0131n detaylar\u0131n\u0131 incelemeliyiz.<\/p>\n \u0130lk olarak bir pod \u00fczerindeki listener’lar\u0131 a\u015fa\u011f\u0131daki gibi listeleyelim. Ben burada “product-gateway-api<\/em>” pod’unu kullanaca\u011f\u0131m.<\/p>\n Yukar\u0131daki resimde de g\u00f6rebilece\u011fimiz \u00fczerine bir \u00e7ok listener bulunmakta. Bizim ise burada ilgilenecek oldu\u011fumuz “15006<\/strong>” portu. \u0130lk olarak bu listener bir pod’a gelen t\u00fcm inbound trafi\u011fi almaktad\u0131r. Yani “product-gateway-api<\/em>” pod’una gelen t\u00fcm trafik, \u00f6nce bu listener taraf\u0131ndan handle edilmektedir.<\/p>\n Bir listener temel olarak i\u00e7erisinde \u00e7e\u015fitli configuration’lar ve gelen request’ler i\u00e7in farkl\u0131 filter’lar bulundurmaktad\u0131r. Yukar\u0131daki resimden de g\u00f6rebilece\u011fimiz \u00fczere, bu filter’lar bir “filterChains<\/a><\/em>” elementi alt\u0131nda toplanmaktad\u0131r. Bu noktada bizim inceleyecek oldu\u011fumuz filter ise, TLS’in etkin oldu\u011funda devreye girecek olan filter.<\/p>\n \u00d6ncelikle a\u015fa\u011f\u0131daki komut yard\u0131m\u0131 ile inbound listener detaylar\u0131n\u0131 elde edelim.<\/p>\n Bu noktada ise, olduk\u00e7a uzun bir response alaca\u011f\u0131z. Fakat ben sadece gerekli g\u00f6rd\u00fc\u011f\u00fcm k\u0131s\u0131mlara de\u011finece\u011fim.<\/p>\n \u0130lgilenecek oldu\u011fumuz filter’\u0131n, TLS etkin oldu\u011funda devreye girecek olan filter oldu\u011funu s\u00f6ylemi\u015ftik.<\/p>\n Bu filter’\u0131 ise a\u015fa\u011f\u0131daki gibi ay\u0131rt edebiliriz.<\/p>\n Bu filter i\u00e7erisindeki bizim i\u00e7in \u00f6nemli olan noktalardan bir tanesi “transportSocket<\/strong>” element’i. Bu element i\u00e7erisinde TLS i\u00e7in gerekli olan sertifika gibi bilgilerin yer ald\u0131\u011f\u0131n\u0131 g\u00f6rebiliriz.<\/p>\n Biraz daha detaya girmek gerekirse, “tlsCertificateSdsSecretConfigs<\/strong>” element’ine bakt\u0131\u011f\u0131m\u0131zda TLS sertifikalar\u0131n\u0131n \u00e7ekilebilmesi i\u00e7in gerekli olan Secret Discovery Service<\/em> (SDS) bilgilerinin burada yer ald\u0131\u011f\u0131n\u0131 g\u00f6rebiliriz. Ayr\u0131ca “validationContextSdsSecretConfig<\/strong>” element’inde ise, TLS sertifikalar\u0131n\u0131n do\u011frulama i\u015flemleri i\u00e7in gerekli olacak “ROOTCA<\/strong>” eri\u015fim bilgilerinin de yer ald\u0131\u011f\u0131n\u0131 g\u00f6rebiliriz.<\/p>\n Mutual TLS mesh i\u00e7erisinde aktif oldu\u011fu i\u00e7in, “ROOTCA<\/strong>” eri\u015fim bilgileri do\u011frulama i\u015flemleri i\u00e7in zorunludur. Ayr\u0131ca bu gereklili\u011fi “requireClientCertificate<\/strong>” element’inin de\u011ferine bakarak da anlayabiliriz. Bizim senaryomuzda “true<\/strong>” oldu\u011funu da g\u00f6rebiliriz. Yani “product-gateway-api<\/em>” pod’una istek yapan bir client, eri\u015fim sa\u011flayabilmesi i\u00e7in kendi sertifikas\u0131n\u0131 da sunmas\u0131 gerekmektedir.<\/p>\n Client kendi sertifikas\u0131n\u0131 sundu\u011funda ise burada devreye envoy’un TLS Inspector<\/strong> filter’\u0131 devreye girer. Bu filter, SNI<\/strong>‘\u0131n elde edilmesi gibi initial TLS handshake i\u015flemlerini ger\u00e7ekle\u015ftirir. B\u00f6ylece bu SNI bilgisi, “filterChains<\/em>” e\u015fle\u015ftirme i\u015flemleri i\u00e7in kullan\u0131labilir bir hale gelir. Bu konu hakk\u0131nda daha detayl\u0131 bilgilere ise, buradan<\/a><\/em> eri\u015febilirsiniz.<\/p>\n \u015eimdi ise client taraf\u0131ndaki i\u015flemlere bir bakal\u0131m. Bunun i\u00e7in ise upstream request’in configuration’lar\u0131na bakmam\u0131z gerekmektedir.<\/p>\n \u0130lk olarak a\u015fa\u011f\u0131daki komut yard\u0131m\u0131yla “product-gateway-api<\/em>” pod’unun cluster \u00f6zetini elde edelim.<\/p>\n![\"\"](\"\/wp-content\/uploads\/2020\/08\/istio_logo.jpg\"){kind=logo}
<\/a><\/p>\n\n
Mutual TLS ile Service-to-Service \u0130leti\u015fim G\u00fcvenli\u011fini Sa\u011flamak<\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2020\/08\/istio-arch.jpg\")
<\/a>Mutual TLS authentication, client ve server olmak \u00fczere her iki y\u00f6nde de trafi\u011fin hem g\u00fcvenli hem de g\u00fcvenilir olmas\u0131n\u0131 sa\u011flamaktad\u0131r.<\/p>\n![\"\"](\"\/wp-content\/uploads\/2020\/09\/istio-mtls-arc.jpg\")
<\/a>Bildi\u011fimiz gibi bir service bir trafik ald\u0131\u011f\u0131nda veya g\u00f6nderdi\u011finde, service mesh’in do\u011fas\u0131 gere\u011fi bu trafik her zaman \u00f6nce ilgili service’in local sidecar proxy’sinden ge\u00e7er. Dolay\u0131s\u0131yla mTLS kullan\u0131larak bir request at\u0131ld\u0131\u011f\u0131nda, istio bu trafi\u011fi client’\u0131n local sidecar’\u0131na y\u00f6nlendirmektedir. Bu local sidecar trafi\u011fi ald\u0131\u011f\u0131nda ise, server’\u0131n sidecar’\u0131 ile bir mTLS handshake<\/a> i\u015flemi ger\u00e7ekle\u015ftirmeye ba\u015flar.<\/p>\n\u00d6rnek Bir Uygulama Deploy Edelim<\/h2>\n
[HttpGet(\"{id}\")]\r\npublic async Task Get(int id)\r\n{\r\n HttpClient httpClient = _httpClientFactory.CreateClient();\r\n\r\n string productAPIUrl = _configuration.GetValue(\"productAPIUrl\");\r\n string stockAPIUrl = _configuration.GetValue(\"stockAPIUrl\");\r\n\r\n productAPIUrl = $\"{productAPIUrl}\/products\/{id}\";\r\n stockAPIUrl = $\"{stockAPIUrl}\/stocks?productId={id}\"; ;\r\n\r\n Task productResponse = httpClient.GetAsync(productAPIUrl);\r\n Task stockResponse = httpClient.GetAsync(stockAPIUrl);\r\n\r\n await Task.WhenAll(productResponse, stockResponse);\r\n\r\n if (productResponse.Result.IsSuccessStatusCode && stockResponse.Result.IsSuccessStatusCode)\r\n {\r\n var jOption = new JsonSerializerOptions\r\n {\r\n PropertyNamingPolicy = JsonNamingPolicy.CamelCase\r\n };\r\n\r\n using var productResponseContent = await productResponse.Result.Content.ReadAsStreamAsync();\r\n ProductDTO product = await JsonSerializer.DeserializeAsync(productResponseContent, jOption);\r\n\r\n using var stockResponseContent = await stockResponse.Result.Content.ReadAsStreamAsync();\r\n StockDTO stock = await JsonSerializer.DeserializeAsync(stockResponseContent, jOption);\r\n\r\n var aggregatedProduct = new ProductAggregatedDTO\r\n {\r\n Id = product.Id,\r\n Name = product.Name,\r\n Quantity = stock.Quantity\r\n };\r\n\r\n return Ok(aggregatedProduct);\r\n };\r\n\r\n return NotFound();\r\n}<\/pre>\nGereksinimler ve Varsay\u0131mlar<\/h3>\n
\n
![\"\"](\"\/wp-content\/uploads\/2020\/10\/istio-install.png\")
<\/a><\/p>\nkubectl label namespace default istio-injection=enabled<\/pre>\n
docker build -f ProductAPI\/Dockerfile . -t ecom-sample-product-api:v1\r\ndocker build -f StockAPI\/Dockerfile . -t ecom-sample-stock-api:v1\r\ndocker build -f ProductGatewayAPI\/Dockerfile . -t ecom-sample-product-gateway-api:v1<\/pre>\n
kubectl apply -f deploy.yaml<\/pre>\n
![\"\"](\"\/wp-content\/uploads\/2020\/10\/kubectl-deploy-apps.png\")
<\/a><\/p>\nistioctl x describe pod product-gateway-api-v1-7996bf7cdf-dz289<\/pre>\n
![\"\"](\"\/wp-content\/uploads\/2020\/10\/istioctl-describe-pod.png\")
<\/a><\/p>\nkubectl exec \"$(kubectl get pod -l app=stock-api -o jsonpath={.items..metadata.name})\" -c stock-api -it sh\r\n\r\ncurl http:\/\/product-gateway-api.default.svc.cluster.local\/products\/1<\/pre>\n![\"\"](\"\/wp-content\/uploads\/2020\/10\/test-request-to-pod.png\")
<\/a><\/p>\n\n
apiVersion: \"security.istio.io\/v1beta1\"\r\nkind: \"PeerAuthentication\"\r\nmetadata:\r\n name: \"default\"\r\n namespace: \"default\"\r\nspec:\r\n mtls:\r\n mode: STRICT<\/pre>\n
portLevelMtls:\r\n 8080:\r\n mode: DISABLE<\/pre>\n
kubectl apply -f mtls.yaml<\/pre>\n
kubectl run -i --tty -n test --rm test --image=curlimages\/curl:7.71.1 --restart=Never -- sh\r\ncurl http:\/\/product-gateway-api.default.svc.cluster.local\/products\/1<\/pre>\n
![\"\"](\"\/wp-content\/uploads\/2020\/10\/istio-call-with-mtls.png\")
<\/a><\/p>\nPeki bu mTLS i\u015flemleri arkaplanda nas\u0131l yap\u0131l\u0131yor. S\u0131k\u0131c\u0131 k\u0131s\u0131m i\u00e7in haz\u0131r m\u0131s\u0131n\u0131z?<\/h3>\n
\n
Listener Taraf\u0131<\/h3>\n
istioctl pc listeners product-gateway-api-v1-7996bf7cdf-dz289<\/pre>\n
![\"\"](\"\/wp-content\/uploads\/2020\/10\/pod-listeners.png\")
<\/a><\/p>\n![\"\"](\"\/wp-content\/uploads\/2020\/10\/envoy-filter-chain.jpg\")
<\/a><\/p>\nistioctl pc listeners product-gateway-api-v1-7996bf7cdf-dz289 --address 0.0.0.0 --port 15006 -o json | less<\/pre>\n
\"filterChains\": [\r\n {\r\n \"filterChainMatch\": {\r\n \"prefixRanges\": [\r\n {\r\n \"addressPrefix\": \"0.0.0.0\",\r\n \"prefixLen\": 0\r\n }\r\n ],\r\n \"transportProtocol\": \"tls\"\r\n },<\/pre>\n![\"\"](\"\/wp-content\/uploads\/2020\/10\/listener-detail-1.png\")
<\/a><\/p>\nCluster Taraf\u0131<\/h3>\n
![\"\"](\"\/wp-content\/uploads\/2020\/10\/pod-cluster-sum.png\")
<\/a><\/p>\n![\"\"](\"\/wp-content\/uploads\/2020\/10\/istio-cluster-detail-fqdn.png\")
<\/a><\/p>\n