Body: <p>My application consists of four microservices. (hr, salary, stock and employee). Users of the application access the "hr" service using http. To fulfill this request the hr microservice communicates with other 3 and sends back a response to the user.</p>
  
  <p>I had deployed this application (4 micro-services) in a kubernetes cluster.</p>
  
  <p>Then I wanted to learn <a href="https://istio.io" rel="nofollow noreferrer">Istio</a> so I set up the same application on a mutual TLS enabled environment and set up http ingress gateway for external access. Now all my services have a sidecar which mandates mTLS communication and external user accesses this using an ingress gateway.</p>
  
  <p>Can you please help me understand what sort of security advantages I introduced by moving to the Istio based deployment? What are the attack points did I just closed? Please point them as scenarios since I'm new to the security landscape.</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-25T09:50:55.590Z
Comments: @simbo1905 could you post an answer?
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-12-14T12:37:37.110Z
Comments: You moved from clear text exchange to cyphered exchange... that's the S in https. I'm unsure of what you're after out of that
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-12-14T12:39:46.173Z
Comments: @Tensibai guess It means I prevented man in the middle attacks between the four microservices ?
Comments: Pasan W.
Comments: CC BY-SA 4.0
Comments: 2018-12-14T12:41:14.287Z
Comments: More sniffing, MITM is another kind and depending on your certificates and how each service authenticate to each other it can stil be doable
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-12-14T14:50:26.877Z
Comments: If your running on private VMs on private networks you haven't closed a lot of attack vectors. if your running on shared VMs and have different environments and different teams running in different k8s namespaces moving to mTLS is a big improvement assume you have good cert management (such as a cloud native KMS service). a lot of companies didn't get the full advantage of containers as they refuse to "multi-tenant" thier clusters due to security concerns. if they can certify itsio as providing good protection based on mTLS backed by a cloud vault they can run less clusters at higher density.
Comments: simbo1905
Comments: CC BY-SA 4.0
Comments: 2018-12-14T15:00:34.670Z
Comments: other solutions in the security space are integrating software defined networking products into k8s that secure intra cluster traffic by policy and include intrusion detection like logging and blocking unexpected traffic. openshift Kubernetes has a couple of vendor plug-ins. Istio as a service mesh opens up being able to apply policy and potentially in the future some of the features of the commercial products (e.g. altering on unexpected connection attempts it blocks that may suggest a pod has been hijacked)
Comments: simbo1905
Tags: <kubernetes><security><istio>
Title: What security loopholes does Istio tackle?
UserDisplayName: Pasan W.
ThreadText: # What security loopholes does Istio tackle?
  
  (Asked by: username_0 on 2018-12-14)
  
  My application consists of four microservices. (hr, salary, stock and employee). Users of the application access the "hr" service using http. To fulfill this request the hr microservice communicates with other 3 and sends back a response to the user.
  
  I had deployed this application (4 micro-services) in a kubernetes cluster.
  
  Then I wanted to learn [Istio](https://istio.io) so I set up the same application on a mutual TLS enabled environment and set up http ingress gateway for external access. Now all my services have a sidecar which mandates mTLS communication and external user accesses this using an ingress gateway.
  
  Can you please help me understand what sort of security advantages I introduced by moving to the Istio based deployment? What are the attack points did I just closed? Please point them as scenarios since I'm new to the security landscape.
  
  **Tags:** kubernetes, security, istio
  
  > **Comments:**
  > **username_2**: You moved from clear text exchange to cyphered exchange... that's the S in https. I'm unsure of what you're after out of that  
  > **username_0**: @username_2 guess It means I prevented man in the middle attacks between the four microservices ?  
  > **username_2**: More sniffing, MITM is another kind and depending on your certificates and how each service authenticate to each other it can stil be doable  
  > **username_3**: If your running on private VMs on private networks you haven't closed a lot of attack vectors. if your running on shared VMs and have different environments and different teams running in different k8s namespaces moving to mTLS is a big improvement assume you have good cert management (such as a cloud native KMS service). a lot of companies didn't get the full advantage of containers as they refuse to "multi-tenant" thier clusters due to security concerns. if they can certify itsio as providing good protection based on mTLS backed by a cloud vault they can run less clusters at higher density.  
  > **username_3**: other solutions in the security space are integrating software defined networking products into k8s that secure intra cluster traffic by policy and include intrusion detection like logging and blocking unexpected traffic. openshift Kubernetes has a couple of vendor plug-ins. Istio as a service mesh opens up being able to apply policy and potentially in the future some of the features of the commercial products (e.g. altering on unexpected connection attempts it blocks that may suggest a pod has been hijacked)  
  > **username_1**: @username_3 could you post an answer?  
  
  ---
  
  ## 0 answers
  
  