How to Secure Microservices Without Traditional Firewalls

hello everyone thank you very much for joining this uh hopefully quick talk we want to talk about how secure microservices without traditional firewalls my name is peter mcallister i'm an implementation engineer of company called trade we're mostly working on service mesh and implementations in enterprise environment and um it is difficult to start talking about it and i know i have a limited amount of time just about vpn we want to cover a little bit how we got here uh how service mesh helps us with microservices and cover network aspects and this presentation actually was originally uh delivered by my colleague founder engineer of detroit his name is ignacy barrera and i'm just repeating basically what he said in his

presentation hopefully adding a little bit more context because he did his wild so and how we got here uh obviously a little bit of history we had one application delivering information from application to user and application was facing internet we had firewall firewall said okay we support with ip it will access everything else be closed then application grown and grown and we had more ports open more services uh delivered to the customer and we decided our consumer and then we decided okay let's break it to microservices or services at least so let's have it on multiple uh computers servers and now we cannot only uh separate between external network and internal network we also need to separate

uh use additional firewalls use dmz or something to separate different parts of application from each other and say only service a can talk to service b on such and such port from search and such ap etc and to add complexity here we actually moved it all to the cloud and the cloud that kind of similar cons concept but now you're getting vpcs you're getting different subnets so it's it gets more complex you also get security groups not only firewall groups so you can do more granular separation of your rights and services right um and when we were in a cloud we decided why don't we break application i wanted more parts and instead of having ec2 instances or

other cloud instances let's run our application as function or microservices and everything on a design board looked absolutely awesome and everything looked absolutely awesome until someone some application or some service experienced some kind of failure and obviously there's so many scenarios uh how it can affect other uh pieces of replication and some of them we tested some of them we didn't test something in our specific favorite brands uh in different ways at what we tested and now we have multiple uh multiple services uh affected by one single failure of applications so it's maybe not complete downtime but maybe it's slowed down maybe there's some delays and somehow we need to deal with it so there's multiple projects that come

in a play some of them open source projects other projects came from established enterprises and companies so uh to name couple of them skywalking as a project that grown up in asia and basically allows you to aggregate metrics and instead of uh collecting everything on every node and get more holistic view what's going on in your application or in your piece of cloud a zip can different approach here so basically put additional header in your pocket and trace it all the way down so you have one big trace that shows you all hopes and where you have delays where you have different performance issues so when we think about uh always different projects and what

they exactly achieve it basically comes to several different aspects first we need ability to discover services so every time when you run service in the cloud that can get different identity different ap maybe even in different region or zone that's going to be running so we need to have some inventory where we can say okay service a calling service b and service b is running here and here and here so uh also if something happens to my service we need to be able to somehow deal with the error so move on load somewhere else um spin up additional instances etc if our application is too busy we also should be able to just stop uh

traffic training going to this specific instance of the service so this instance can recover from extra load extra extra requests that we didn't expect with a specific service uh foot would get and also bad pressure and tracing i kind of already described this so then we came up with ideas that we need applications or services that know about all these things all additional services or additional um workloads and can adapt to it so it's kind of self-healing self-discovering services and it came up in multiple different uh form factors and in one environment you can see all of them you can see java and node run different services of the same application so now in every specific implementation

you need to implement to introduce with pillars that allow you to function correctly and it cannot be it can be a little bit difficult to ask developers and expect them to implement the same functionality in all different applications even using libraries because you need specific libraries for every um every type of code so if we kind of take step back and look how we originally delivered so don't uh get confused here with envelopes we're talking about packets from um not a accessing uh being delivered to not be so we had this problem many years ago with introduction of basic networking we needed data to get from point a to point b and we come up basically with two

different uh models uh they have the same meaning behind them but a little bit different so in general you have these different layers and your application doesn't really know what's happening on your physical layer right so you have some kind of drivers and other things on different layers that take care of it and make sure your zeros and one on your wire delivered correctly and free of errors now it seems we have we hitting exactly the same issue but on higher levels so we have applications that needs to make sure these things that we already discussed are there so we can trace we can get metrics we can understand when up other end of application is too

low that when traffic needs to be redirected somewhere else so everything here is the same but now we just kind of increase our attention and looking at application level so same problem again non-application level so and here in the play service mesh comes and service mesh delivers exactly what we already discussed so consistency so instead of having different libraries for different pieces of your application service mesh provides this identical approach to all of them pieces and provides it from outside and it's centrally managed so you don't have to go in every service and configure it you describe your rules permissions policies and they get propagated across all your fleet um and of course it needs to be

very adaptive to the changes so you cannot really uh redeploy your application every time when there's some changes happening of how you want to monitor secure or trace your application so three pillars of service mesh networking observability and security so we make sure traffic is going in the right direction we have tools uh to monitor how traffic is going and we make sure there's only traffic that needs to be served is served uh and the idea here is to take it away from developers so it's not developers who's taken care of it it's a service mesh that takes care of these uh specific uh aspects of your application and developers can concentrate of what they

should be doing applications that delivers value to your business uh at separate we very closely work with envoy open source project an initial open source project and um you can read more about what i exactly anw is doing of what i'm covering here is mostly focused on envoy but i can ensure you that all other uh service measures deliver a similar similar experience and similar concepts and um if we're looking at control plane so there's a different again different mechanisms that can deliver it but again control point make sure you do all configuration and central place and it gets delivered to all your microservices at the same time if there's any changes changes propagated everywhere at the same time

from the same source of truth or central location i if you look at on a traffic aspect of service mesh of what's happening there we basically can say how much traffic going in different directions it's very helpful if you do canneries deployment so some people call it green blue uh different a b whatever but idea is you have new version of your application you want slowly migrate traffic there you don't really need to configure anything on different layers you just tell your ingress and your proxies uh sidecast how to deliver it and i kind of missed covering it but a service mesh idea you have fanboy that runs on every port and way or is your proxy sidecar that runs on every

port and kind of fronts your application your service right so service only talks to uh android proxy and only proxy talks to external world and two services they both stocks when we proxies so service a uses its proxy to reach proxy on service b and service b proxy talks to service b so in this specific case we just say okay uh for this specific service so much should be going to version one and so much going to version two and we don't really need to do anything so if you go to kubernetes you need to deploy so many instances of which service here uh proxy is smart enough to understand how traffic is delivered and

allow you to do that it's not only aspect that i service measures doing we also are providing free silency so you can specify service a uh is not responding try it again so many times with the interval of so many seconds or you can also figure out if there's some anomaly in your behavior of your fleet of services and if we call it outlier detection and basically exclude the service from circulation um also if some services are very busy they're circuit breakers i'm sorry that deliver ability to stop traffic or going to these busy not so busy services um also if you're tasting application it showed here in the middle of the screen you want to say

i want so many failures included in my traffic and see how your application responds so it's main aspects of traffic management and next aspect is uh observability or telemetry and the best thing here that you should understand its consistency so because again it's not multiple libraries it's the same proxy fronting every service it collects metrics in exactly the same way uh uses exactly the same language use exactly the same measurement units and always delivered to the central plain way it's so aggregated and uh managers of the system can understand better how traffic works moving to security and [Music] aspects of security so service mesh allows you to set up certificates on every for every service

and this certificate in android we use spiffy includes your identity intensity of the service so it allows to create a rule saying service a only can talk to service b it cannot talk to server c and set up any rules that fit your organization to make this very very controlled way of delivering um specific information to specific service so make it really micro service specific what information available to who and uh with spf certificates uh they signed certificates and they have of uh ins inside of the certificate they have service identities so no one else can claim i'm service a only service a can claim and because it has proper keep or certificate um at the same time even we have this

identity there's a concern that if traffic going i in open [Music] text someone can listen to it someone can capture it someone can steal confidential data being transferred between microservices and here we come to two uh different concepts pv i kind of covered already so a little bit more details here so it's uh x 509 certificate and that has identity another thing we can do here we can use uh encryption when traffic goes from one side to another side and for encryption we use something called mtls so mtls is basically mitchell tls authentication so it means in a normal world you go to paypal and paypal tells you okay my certificate is valid you can deal

do business with me empty os it's a little bit different so ntos i you as a user also need to present certificate saying i'm your user uh paypal and you can deal with me i'm not some hiker from [Music] somewhere you've never been to right so it's uh i'm valid party for you so it's what mtos is and again using proxies here we are able to uh exchange with certificates and uh do encryption using them and this encryption is only available if mutual trust exists so it brings us to basically core of my presentation and topics that we wanted to cover the most so you have microservices running in google and some developers trying to get an aws

let's say you have development shop because of cost hosted and gcp and production aws so in traditional world you create vpn you create vpn between your own payments aws gcp and you have to set up certificates update certificates make sure your trust with specific networks it's a lot of work and a lot of troubleshooting and we all know sometimes it breaks and now you have also console that administrator wants to access all these services or do some testing to provide if you want to do some on-premise testing to your clouds and now you need to set up extra certificate and do extra stuff and all that very dynamic and it changes all the time and you need

to have some platform to keep it all together so idea that i just explained idea of two parties having certificate and they fronting microservices and they rotated on permanent basis can be applied here basically we don't need vpn anymore we can use and i know it's kind of very bold statement but it's what i'm working with enterprise customers and it's what we see every day we don't really need this specific uh approach we don't need vpn anymore we can just do everything using a certificate that issued to the services because services must trust each other and to communicate with each other and these services can be in any cloud it may be multiple services they can have

different ip addresses it doesn't matter anymore because in front of them they have proxy and proxy have automated automatically issued a related certificate and you can set up in service mesh rules who can talk to you based on your application values based on your services not based on specific regions or ip addresses so uh from me as a networking guy and security guy moving to servicenow space it sounds mind-blowing and almost impossible to understand because we were building vpn for so many years and now we don't really need it so i'm running out of time there's a little bit of coverage what different parts of service mesh provide and i think we covered all it

and only additional thing i wanted to say um i hear that i'm really asking everyone who's uh interested in the project to go on with websites and links and see if they can contribute and it doesn't matter what you can contribute you can do some gamma you can write some documentation you can write some piece of code this projects really really needs contribution and contribution speech especially for audience like besides vancouver audience that really really focuses on security and just to mention one more time that original talk was provided by our engineering nazi barrier and basically i just did uh recouple it here thank you very much and hopefully you were able to learn something new

for in this short period of time