Microservice architecture is very popular today. The panel talks with microservice security authors about their book and all aspects of securing microservices.

Hello, and welcome to another episode of adventures in dot net. I'm Sean Kleby, your host. And with me today on the panel is Joel Schobert. Hey, Joel. Hey.

How you doing? I'm doing pretty good. You know, it's almost Halloween as recording here. So I'm a little disappointed because Halloween's one of my favorite holidays because it's all interactive and things like that, and you're really not gonna do much this year because of all the COVID things. We'll we wanna be safe.

So Yeah. Not a good year for parties, is it? No. It isn't. So we'll try to make the best of it, do what we can.

So with us today, we've got Prabhas Serradina and Yuanthias. And what we're gonna talk about is microservices security. So say hi, guys. Hi, Sean. Hi, Joe.

Thanks for thanks for having us on this podcast. Hi, guys. Thanks for having us, and nice to meet you. Yeah. Definitely.

Definitely. So thanks for coming on the show. So why don't you you know, let's start with Prabhav. Why don't you give us a little rundown of who you are, what you do, and how you got into development? Yes.

So I'm Prabhav Srivadir. I'm the VP of the CTO, security, at WSO 2. And, also, I, manage or lead the WSO 2, I think, which is an open source identity and access management product. I've been with WSO 2 for last 13 years and, like, since the very first day I've been working on this product, that was writing server. It's all open source.

It is under the the most business friendly open source license, Apache 2. Yes. So my career as a developer and also, as an IAM professional started from, w s o two. Prior to that, I worked in another company for 3 years as a software engineer after after my graduation. And I was initially, like, based out of Columbus, Sri Lanka with, Nuwan, and I moved to San Jose in, 2015.

Yeah. Since then, been here. Yeah. K. And is all that experience that you've been is that with dot net or you've been working with different environments in different languages?

Yeah. So mostly, we work on, Java. So Java is a private programming language we use to build all the WSL products. Yeah. Okay.

Alright. And how about you, Noah? What do you do? Yeah. I'm Noah Andes.

I also I'm the VP and deputy CTO for the API management and integration space, at WSO 2. So similar to the identity server, we also have two products called the API manager and the enterprise integrator. So I'm basically responsible for for the r and d, and the road map and the vision for those products. So I ended up in computer science, you know, pretty much similar to how most people end up end up on it. So I chose computer science, went to college.

And then after graduation, I ended up in WSO 2. K. So with, we're talking about microservices, API security today. Do these concepts kinda apply to all languages and and environments? Yes.

Yes. So microservices 1 and then again, APIs. So those are mostly the artificial patterns. And the concepts around those are language, atmospheric. So Nuan and I, worked on the book, Microservices, Superdition Action.

So we started this probably 2 and half years back, and the book was out, 3 months back. So there, we try to be as much as language agnostic. We use different, like, JavaScript and JavaScript to, write our samples. We must check how things work, but at the conceptual level, they are language agnostic. And even how you apply security, that's that's the language agnostic.

That's the beauty of microservices too. And once again, it's a key, like, design principle of of microservices. You should be able to interact with multiple micro multiple microservices written in different program languages so you use, like, the the the microservices that you develop using different technology stacks. That's the beauty of microservices. And, moving forward, like, when you are when when you are a large company with multiple teams, if you follow Microsoft design principles, you should be able to interact with different teams with different technology stacks.

Okay. Great. So, if somebody's first getting into that let's let's first define what a microservice is. You know, a lot of people probably have different definitions, but what does microservice mean to you? Yeah.

Okay. So no one can share his idea to so once again, Microsoft itself isn't all of that term. Like, people have defined it in different ways. And so if you look at a little bit of, like, history, from the so service oriented architecture here. SOA itself defines what a service is and the principles around a a service.

But somehow, over the time, when we implement services under the SOA design principles, we violated some of the key principles. For example, the scope of our service. Right? So ideally, even with, even if you follow a SOAR Design Principles, your services should be well scoped. Right?

So that doesn't mean that scope should be reused, but it should it should follow this single responsibility principle. So when you design a scope of a service, it should adhere to their single responsive principle. But most of the services, like, SOAR based services, when they were following SOAR design principle, they didn't care that much about this the primary principles of SOAR. So they ended up building monolithic application, monolithic services which violated the principles. So that's why some people call microservice as so done right.

So I, to some extent, agree with that. But then again, microservice concept has gone well beyond architectural principle or architecture pattern. Now it has become a culture. So there are a lot of things built around this key design principle. For example, at the baseline, at the bottom line, you need to have Wellscope service.

Then again, to build the Wellscope service, you need to have the right team structure. Ideally, you should have small teams. Right? Maybe, like, 10 to 12 people a team. So then they can look after narrow scope sales.

Right? So there can be there there can be a team which manage 1 or 2, like, few sort of microservices. So that's one thing. Then another thing is one one key, motivation behind for most of the companies to move to this microservices architecture is they want to get things done quickly or reduce the time to production. So if you are reduce the time to production and if you want to push, new features and changes to production as as soon as possible.

And also that has to be done in a reliable reliable manner. Right? With all the test and everything there. So you need to worry about the CICD pipeline. So that's where the lot of tooling around ci CICD pipeline has built in.

And and then again, for to make the testing much easier, you should be able to test the services that you build in in multiple environments. Right? So with without without without any fuss. So that's where the containers has come into the picture. So with containers, you deploy Microsoft you deploy Microsoft container.

So it can be deployed on any platform. So with with no major fuss, anyone can, like, spin up a service without without high dependency on the underneath platform and and test stuff. And also that helps you to deploy your service in multiple platforms. So that has helped to make this, the time to production less. So so that's what I'm telling that the my my service has gone beyond just by being a design principle.

Now it has become a culture. So Netflix, Amazon has been, like, PR finance in taking this Microsoft culture forward. Okay. So we kinda got a baseline for what microservices are now. So if I build a microservice, I probably gonna build many microservices, and all that interaction between themselves and between the users all needs to be secure.

So where do I start? What's the first first thing to know about securing microservices? Yeah. So I can probably take that one. So, you are right when you say, like, when people build microservices, they probably end up with, with a lot.

So one of the key things to securing microservices basically is to ensure that your entry point into these services are secured. So usually, what what we do technically is to have something called an API gateway, which basically grants all the access into the microservices layer. So all the traffic that's coming in from user applications and so on go through a layer which we call as the API gateway layer. We also call this the ingress, point, in a in an architecture. So everything goes through the gateway, and the gateway is the one that does all of the authentication and authorization.

So we use the gateway to secure, north to south, what we call the the external to internal communication part. And by that, you ensure everything that's coming in into your service layer from outside is secured. So that's like the, level 0 or level 1 of securing microservices. And then, of course, you have once you are in, once the request is in, it may go through several hops of microservices to ensure the business logic is catered to or the request is catered to So so then you have additional layers of security, which we call as the east west traffic, where services communicate with each other. And we have many protocols, for securing those microservices based on which communication channels they use to, communicate and so on.

So it could be what we call as mutual, TLS, sometimes, JWT based security, and so on. So depending on the type of communication, how you secure these interservice communications may vary. And to add to that, like, if you look at, how we structured our book, so when I when one and I worked on this, so we did a lot of brainstorming, like, how we want to structure our book because Microsoft security has, like, a a broader landscape. So we divided this into few sections. So one is edge security.

So that's what Nuwan talked about, like, securing the APIs and all south traffic. Then the other, other area we need to worry about it, the service service communication. So when one service stores another service, how do you secure that communication channel? That's east west communication. Then, we also need to worry about deployment.

Like, how do you secure, the containers? Then, how do you secure, the Kubernetes environment? And if you are using a service mesh, how you can achieve a zero trust network pattern, using a service mesh. That's a deployment side. And then finally, we talked about the development.

So when you develop microservices, what are the, the best practices you should follow in writing code, and also what are the static code analysis tool, dynamic testing you need to carry out, and how you can integrate those into CICD pipeline. So those are the 4 areas we discussed in the book. Okay. So get us started on, you know, the first area the first things that we need to know once we built the microservices and how to secure it. Yes.

In one, you want to get started with the, probably, the edge security? Yeah. Yeah. Sure. So so like I was mentioning, the the first thing that you want to consider when you're building a microservice is to figure out who's going to be using this microservice.

So there are microservices that are serving requests coming from the outside world. Like, when a user presses a button on a mobile application or on a web page, a request might end up on a microservice. So if it's that kind that kind of a microservice, you are to make sure, it is secured at the edge. Meaning, you have to make sure the request comes through a gateway, the gateway does the authentication, and then the gateway propagates some security context to the microservice. Because beyond the gateway, also, we need to make sure that there's a trust established in that channel so that we when the request lands up on the microservice, we know, that it came from a trusted source.

So that's one of the first things to note, like, who is going to be talking to me. If it's an internal microservice, it's an internal comp component that's talking to me, then I have to look at what is protocol. So the second thing you have to be considered about is, what protocols are being used to communicate with me. So my microservice could be one that's being served with CTP, one that be that's being served over gRPC, or it can be an event, so on. So based on that, you have to choose the appropriate mechanism of securing it.

It could be mutual PLS. It could be OAuth based security and so on. So these are some of the basic things to consider, like, the first most things to consider when you when you are thinking about securing a given microservice. K. So at at that level, it's really just like any other application.

You gotta authorize and authenticate your users to, the things they're gonna be accessing. That's right. Yes. So at the end end, we need to worry about authentication and the authorization. And also at during the service service communications too, we need to worry about the authentication and authorization.

So if you take an API, so basically, the microservices, as no one mentioned, are exposed to the rest of the world via an API. So you have an API gateway, which will route traffic to an upstream microservice. So as, Nuwan mentioned, so microservices are exposed to the rest of the world to an API gateway. So API gateway will route traffic to the upstream microservices. So at API end, there are 2 types of users.

1 is a system can access an API just by being itself, or else a system can access an API on behalf of an end user. For example, when you when you access Netflix. Right? So as a human user, we have Netflix account. But either the Netflix app or the smart TV application is accessing the Netflix APIs on behalf of you.

Right? So that's a system accessing an API on behalf of human user. So when you do authentication and authorization at the edge, you need to worry about that. So that's why, as Nuan mentioned, all 2 has become the defect or standard for securing APIs at the edge. Then the API gateway will verify the secret at that level, and we'll terminate the secret at that level, and we'll generate a security context, which carries the client application and the the end user information, and we'll pass that to the upstream microservice.

So then, which security mechanisms you need to use to protect or enforce access control checks and authentication at the each microservice level depends on the protocol that you use. If they the connection between microservice can happen over gRPC, HTTP, or or Kafka, like, in an event event driven world. So you need to pick the things that you need. The question you ask, right, so in that case, they are just like another application. Yes.

So they are just like another applications, but something we need to think about is the single responsive principle. So single responsive built principle is not just applicable for the business logic you write. It's also applicable for the nonfunctional requirements. So if you are if you are a developer who's building a business logic, you should not be overloaded with how you how you handle security for your microservice, how you handle observability for your microservice, how you handle analytics for your microservice. Those should be done outside your microservice.

That's where the service mesh comes into your picture. So as a developer, I worry about my microservice and I build that. So now I did put in the container. Now we use a service mesh. For example, Istio service mesh.

Then all the requests coming to your microservice from the API gateway will be intercepted by a proxy. So in the Istio mesh architecture, it's an online proxy. So envoy proxy will intercept all the requests coming to a microservice and will enforce authentication, authorization text, as well as gather analytics, perform some of the, like, routing stuff, do auxiliary stuff will be done from the envoy process. So that's why we see service mesh pattern is a is in a way is a good way to implement the 0 trust network pattern. The reason is the one basic principle behind 0 net network principle is you don't trust the network.

Right? So that's the bottom line of 0 trust network pattern. So if you don't trust the network, you should enforce all the security checks as much as closer to your service or the resource. So when you deploy only proxy, collocated with your microservice, then no one can reach this microservice without going to the Envoy. Then you validate everything at the Envoy layer, taking out the complete burden of doing secret checks from the microservice.

Yeah. Great example. So if I had so to take that, like, a little further, let's say I was at a company, come in there to implement something for them. And let's say they had an API server that was just JWT. That's what it took.

JWT HTTP. So something kinda classic. Now I'm gonna make an app, and it's just gonna be browser based. I'm gonna put a UI server. So at the very start, does my UI server go inside that API gateway with the API server, or does it say on the outside and has to call in through that layer to get to the API gate to get to that service?

Yeah. So, it'll basically, be outside, but how it'll so you I I assume you're talking about the end use application or the UI application, the web application here. So it will be outside. So, however, the the flow would be the application should first authenticate itself with an authorization server before even it actually gets to the API gateway. So do that do that, you basically, would typically use the OAuth protocol and, do an OAuth handshake with an authorization server and obtain a key, which is what we call as an access token in the world of OAuth 2.

And then your request that comes to the API gateway should bear this access token, which the gateway will trust will know how to trust. And and then the gateway will validate this access token and let you in into the let you're requesting into the system. Nice. So if I do that if I use that strategy, then in the browser, after I go to the UI server, I show it on the browser, make my user log in, get an OAuth token, would that work out then that if I needed to make an AJAX call through the API gateway back to that API server behind that, would that same OAuth token then be used for the Ajax call so the browser can do that as well? Yes.

That is correct. So even for for the Ajax calls, it will it will be passed. So there are two ways of doing this. So there are cases, like what we call as a single page applications sometimes. So they, store the access token and use it for every request that goes in into the API gateway.

So and and there's another pattern which is being used commonly, which is you have another proxy, a web proxy between the API gateway and your web application. And what this web application or web proxy does is to kind of map a session cookie with an OAuth token that it maintains on the server side. So between the application and your web proxy, what you actually maintain is a a session based on a cookie. And the, proxy basically maps that cookie into an OAuth token and gives it to the API gateway. So both of these patterns are used in, different kinds of web applications.

It sounds like there's probably some pros and cons of that. I mean, I'd be guessing that mapping approach, in some ways, makes a little more security because the browser's not even seeing the OAuth token that's gonna be used to get through the gateway. Is is that some of the pros and cons? Yes. That is correct.

So one of the these are some of the problems that have been there in in the OAuth, some protocols itself. Like, if you look at it, so OAuth had this implicit grant, which was intended for these kinds of unsecured JavaScript based applications. But due to some of these limitations, now that protocol or grant type as we call it is no longer recommended. So yes. So whenever web applications have problems, you know, storing the, token on the browser side and so on, they employ these kinds of mechanisms.

But now what is happening is there are newer mechanisms being introduced to get rid of these problems too. So there's there's something called PKC that's coming up, that that's there and then there's several other mechanisms that are solving these problems now related to storing the tokens on the browsers and so on. Oh, great. Okay. And now what I've noticed right in my apps as well, the idea of kind of trying to follow the single responsibility model is really nice.

So you you're writing your service, your your service on the back end, and it's great not to have to worry about a lot of that. And I think that works quite well for authentication. Like, you are who you say you are. But what I found is when it gets into authorization, like, can you do this thing? Or how much data should you be able to see based on maybe your role within the organization?

What I have found when I'm programming that there's no way to keep those concepts out of from going very deep into the service call you're writing itself. Are you guys finding that same thing that there's really no way around that even if you do have the idea of single responsibility? You can't really take the idea of, can I do this thing out of your service? Right? That's right.

Yes. So in in authorization, we see 3 levels of enforcing the access control rules. So one is at the API gateway. So at the API gateway, you enforce post screen access control policies. For example, who can do a get to the customer's API?

Who can do a post to the customer API? Right? So once that is done, you discuss your request to the Microsofts. So at the Microsofts level also, you have interceptor. That's the the online proxy in a typical service mesh environment.

So at the only proxy level also, you can enforce certain access control policies specific to that microservice. Right? For example, you can say only you can do a get to the customer service only if by this particular role, and you can do it between, this time of the day. Right? So because in a in a typical corporate matters environment, you have the API gateway and set of microservices.

So the the governance of each microservices would come from different teams. So they may have their own access control policies, which are enforced at the microservice level. At the same time, corporate level access control policies can be enforced at the, like, initial entry point to your Microsoft deployment. That's the API gateway. So the enforcing mic services, the access control policies at the mic service level is a second level.

That is more fine grained than the first level. And the third one is what you mentioned. That we call as data entitlements. So that means you cannot simply in like, enforce an access control policy without see the response. For example, you can see, you can do a get to the employee slash salary.

Right? But you can only see the salaries of employees. Let's say, you can see if the salary is you can see the records if the salaries are greater than, let's say, 10 k. Monthly salary is 10 k. Right?

If the service are less than that, you can't see it. Oh, either. Right? So, basically, you you do an access control check be based on the data that comes from the the data res response. So right?

Or else data comes from a data source. So that's where those stuff actually the optimal way to do that is at the application itself. But still, you can externalize the policies. You can still write the policies outside and evaluate those stuff in the application level. You cannot totally get rid of that, but you can minimize, like, how much you need to worry about.

For example, open policy agent has become, like, the de facto standard for defining these policies in this cloud data environments. So they have a language called rego. So from rego, you can write the policies. And even Sacmal was popular sometime back, but now due to complexity of some Sacmal, no one is using that. But there are there are they should do what you said before, to to to do the data environment.

For example, in SACML, there's a concept called obligations. Right? So what happens is, for example, like, you whenever request comes, you talk to the point. Point says, okay. If the employees is the if the requester is in the HR admin role, he can do a get to the employee salaries, but with this obligation.

What's the obligation? He can only see if the salary amount is greater than 10 k. Right? So that obligation itself become a string, and you pass that string to the application, and application should know how to interpret that stream. Right.

So you can you can minimize those stuff, but still yes. So there are some dependence on the application side, how you implement, those access controls. Yeah. I think that's a great example because it covers, like, how much you can delegate and expect your framework to do for you. And then you you in this example, you realize you still have to do some work in your actual microservice.

I like that example of those different levels. You can just add the API level maybe, say whether you can call it at all or not. This is all or none kind of approach, which is great. Hopefully, most of your stuff fits in that, which is nice because it's the easiest. Yeah.

And then kind of at the microservices level and then down at the data levels where it does get pretty involved. Just to take your example a little further. Let's say I was implementing the system. I like your salary example. And let's say in the salary example, if I had the role of HR, of course, I could see salaries because that's just part of the job in most HR companies.

Yeah. But then let's say we make it a little trickier. Let's say I can also besides getting all the data about the employees, I can get salaries if I also am your direct manager, and I'm higher than just a first level manager. I'm at least a senior level manager. So now we're getting into things like the relationship between 2 people and the data and stuff.

What would be a reasonable approach if somebody had to solve that kind of problem? Where whether or not you get to see the salary for these people, it depends on the relationship between you and them. So it's not as obviously just a simple role that you have on your own. It's also a role you have relating to the people, the data. Yeah.

So yes. So basically, when you write those policies, like, if you take, in in even in OPA and even in. So, basically, like, in the, the policy architecture, there's a concept called policy information points. Right? So you define the access control policies in what are the programming language the language you need, ACML, OPO, or any language.

Then to evaluate these policies, you need some data. Right? So, for example, your policy can say, you can view records of employees who are directly reporting to you. That's the policy rule. Right?

But you don't hard code any of these roles. Right. So now for the request, you send your name. Just the name who is trying and the name of the person who you want to see the salary. Right?

So now you pass that to the policy engine, then policy engine will talk a policy information point to retrieve the information, role of you, and role of the person who you want to see the salary of. And the relationship between those two roles, you feed into the position point from multiple other data sources, and then position point makes a decision. So you decouple the data from the policy's fruits. So that's that's a, like, common way of doing that. That's nice.

I mean, this one of the things I think fits in very well here is the idea of, like, really how complex is your project and knowing some of that at the start. I mean, we've all seen projects where, oh, yeah. Yeah. Security. You know, maybe we'll add it at the end or something.

And then you think, oh, I'll do a little bit. I'll just do a JWT token. Oh, okay. Well, now I need a couple rules. And then if your project, unfortunately, does get all the way down to where, oh, no.

Now I need a database secure database decisions on what I can see and can't see. At that point, a lot of times you start to wish, wow. I wish I would have started differently at the beginning of the project. So I think this is one of the things that I really like about this book is you guys are trying to cover, like, the different levels at the start. So somebody could read this and try to figure out, hopefully, before you've written a bunch of code, what level am I gonna need to target in the end?

And if I really need something very detailed, wow. Maybe I shouldn't be writing that. Some of these frameworks may do a lot of this for me. On simple projects, a lot of times, it does still pay just to write something quick for yourself. Yeah.

And to extend that example, like, especially with what what I told before, it's it's common networks like microservices or any other applications that you deal with. With microservices, we have certain constraints. You don't like, when you do access control checks at each microservices, the proxies at each microservice, you you don't have direct access to all these data sources. Right? And, also, expecting each microservice to access those data service is not that good because there's a performance impact.

You always need to talk about data to also retrieve information. To to fix that issue, what you do is mostly at the API gateway level, you validate the incoming request coming from the client application. After that, you create a JWT to embed the user's information into that JWT. So that JWT may include user's roles, other information, and you pass that JWT between microservices. Then when you want to make a policy decision, that policy decision point will have access to that JWT, which carries the information.

So that JWT itself will act as a data source for the policy decision point to make decisions. So you don't need to talk to get multiple datas all the time. You pass the information using a JWT. Very nice. And I've I've used JWT specifically on a couple projects that were just HTTP.

I'm not as familiar with is JWT becoming common with other protocols as well? Yeah. We can send JWT or other stuff too. No one you want to talk about it in book, we talk about how to use JWT with Kafka, GRPC, those stuff too. Ah, nice.

I accept Use a familiar mechanism for many different types of, transport protocols. Yes. Exactly. So so JWT is kind of becoming standard now in the sense it's being used over multiple channels and protocols. So even over, GRPC, you can use CWT to secure Kafka channels.

You can use, JWTs and so on. So it's basically becoming a common way of passing user context and and claims, securely. Oh, hooray for standards. Something we can rely on. Right?

That's great. Okay. So so so we've got kind of a a basic high level idea where we're covering many different methods of doing author authorization, and I think authentication both is, have you guys so what I found when I'm doing things is usually the authentication. Is it really you? Is has been more standard and followed more standards than the authorization?

Because authorization is for has things finally caught up in the industry so that authorization is becoming more standard than it used to be? Yes. I think yeah. So in in authorization, as you said, we don't have that much of standard. So once again, there are 2 two two parts.

So one is how to communicate an authorization decision from a policy decision point to the enforcement point. Mhmm. Right? And the other part is how do you represent the authorization logic as a policy in a standard bid? So, for example, it addresses that concern.

The policies are there. So you can write Sacmal the the authorization policies in Sacmal standard manner. And, also, Sacmal defines a request response protocol. It defines, like, how the PEP should communicate with PDP. Now if you take OPA, OPA is not a standard.

It it isn't it's an open it's an open source project. Right? But still not a standard. It it didn't come from a standard body. Right?

So OPA has its own program language or rigo. It defines a way, like, a way to write these policies, and, also, it has more flexibility to request response. You can have your own request which is a decent payload. Only thing is your police should just understand the language. What we are seeing is since there's a lack of the standard for, like, acceptable policies.

For example, SACML was rejected by most of the people because it's of this complexity. Due to the same reason, people started to build their own standard for authorization. For example, Amazon. So Amazon uses its own access control policies written JSON. Right?

Then the OPA came as a news the new new project, and there's another one called speed. So speed, similar to OPA, they build their own language to, write policies. It's also open source. It started at Oracle. Now it's maintained as a different project called speed plus.

So there's another another project too. There are several other open source projects to represent access control policies, but out of all of them now we see open is dominated. But on the other hand, for authentication, we see a lot of protocols, like, for like, SAML 2, which came around 2005. Then OpenID Connect was there. Now we have the O2.

So once again, O2 is more than authentication. It's about access delegation. So how do you it's a it's full. It's an authorization framework for access delegation, which has become the de facto standard for secret APIs. That's great.

So if you fed this down so somebody grabbed your book and kinda read and they would understand, like, a lot of different options, what's going on out there in the industry. Now if you came down to, like, a specific project. Let's say you let's make it real specific. Let's say some company had maybe acquired some technologies, and they had an API server written in Ruby on Rails, and then one written in Microsoft m MFC. So the the the MDC model for for Microsoft.

And now we wanted to take a look at implementing authorization and authentication for those. At some point, you're actually making the call to these authorization systems. Can I do this thing? So does the ability to use these different standards depend upon how much support is in your particular language and maybe even your particular framework for interacting with that? Or do you just write code from scratch?

Or do most of these frameworks have libraries that are crossing a lot of different language? What's the kind of the state of the system for for actually making it real specific to your specific technology? Yeah. So I I can take a stab at that. So a lot of languages do have, libraries and support for doing these kinds of things.

But, however, one thing you have to keep in mind is it's kind of always good to to offload the security to a different layer and not embed it along with your business logic. It does have it has it pros and cons, but the reality of the world is, like, these services are being consumed by multiple parties. So you may expose these APIs to a web application today, but tomorrow, your your business may make a decision that you want to build a web mobile application consuming these APIs. And the way you think about security, based on who is going to access this and where they're going to come from, what kind of devices are going to be consumed, these services are going to be, very different. So you have to make changes to your, security layers based on these kinds of decisions.

So it's always good to offload, these kinds of security policies to a external layer, which could be like an API gateway layer. And even, like, if you're thinking about the microservices, like architecture, like, Prabhat was talking about before, like, you have this, proxy, Ravi, sitting just before your services and granting access. So you can do the security at those individual proxy layers and so on. So my my view is that it's always good to use something in front to take care of all of that. I think that's great.

Yeah. The idea I think the idea, Nuance, great. The idea that you do it and delegate that up and get that out of your microservice completely. Because once you start having to get into all these different applications, especially if they're in 2 different languages, you know, maybe your company acquires some other companies, whatever the case may be, then you're it's getting very messy. Now if you did that at the API level or API gateway, that's wonderful because then the access is done up there.

You're done. And the microservice, there's actually no code at all for wondering if you can do the thing or not. But now if we drill down more to a case where, yes, we actually have details in here or that microserve service needs to show different amounts of data or make some decisions. And it just is gonna have to be aware of what the authorizations are that this person has. So now if you were in that more detailed case, and you said, oh, I wanna look at using one of these standards.

What's a good way to find out, like, how much support is there in my particular language for one of these different standards for helping me out? Yeah. So it's so most of these standard languages now have libraries for all of them. So, basically, if you look at languages like Go to Java to to c plus plus even, they they have languages and not sorry. Libraries.

And not just libraries, but even frameworks. So Spring Boot, for example, is a good framework for for Java for for Java applications for doing these kinds of stuff. So it's pretty easy, I guess. So to to find, support for this. So in most cases, what happens is in, like, the example that you mentioned, these policies or claims will be embedded in a JWT and passed on to your microservice, whatever the data it needs in terms of authorization context.

So what you really need to look for is, how much of a support you have in your language or library or framework to to read these JWTs in a trusted way. Basically, the the things that you have to do is, trust, verify the signage of the JWT and then pass it, which is adjacent, and then look at the claims of it. So these are the basic things that you should be looking for. And I guess most programming languages now have standard support for this. So it should be pretty straightforward.

Oh, that's great. Yeah. You know, one of the things that I've run into a lot, especially on teams that are a little larger, is if you have a good nice security system, everything's great. And then, of course, you want all of that to be an action when you deploy it. A lot of times when the developers are in development, they don't want security to even be there or be in the way.

Because a lot of times it just creates more headaches and testing becomes very difficult and all of a sudden this browser has to do some kind of login to get tokens. What have you found are, like, some of the main key points then for trying to keep both developers happy as well as, make it work well in production? Yeah. So I think, again so the the the answer is to offload the security, to a separate layer, which is kind of, like, the best way to achieve this. So in those kinds of situations, it's what you will typically do in a development kind of environment is, basically, you will switch off these layers and grant direct access to your microservices or or whatever the services that you're exposing, and you will basically bypass these layers.

And when you move that stuff to production, the network infrastructure will not allow those kinds of direct communication. So your network infrastructure will ensure that the communications needs to happen through these, secured channels. So if you can manage to offload the security into a proxy kind of a layer, I think it's it's, easy to manage this. But in cases where you have business logic associated with claims and so on, where you have to read the claims from a JWT and apply logic based on those capabilities, so in that cases, it becomes it becomes, it becomes hard. Basically, it becomes impossible for you to kind of ignore security because your logic now relies on the security context.

So, again, there are various ways you can get around this, like using, mocking frameworks and and so on, like, similar patterns that we used in for writing unit tests where you we, you know, where we use mechanisms to mock databases and mock services when we are running unit test. So there are mechanisms like these as well so that you can apply some flags in your code to make sure that this is just in, this mock just happens in development state only. Yeah. That's great. I I really agree that that if you can do it through the networking level so it sounds like if you do that where there is just an API gateway or something, it becomes so simple that you actually just buy your network and your routing tables.

And then dev, you're going around the API gateway just right to the back services, and the services, they don't know any difference. They don't know whether the API gateway was there or not. And then in production, everything must route through the API gateway. And so by the time it gets to the service, it still doesn't know, but it's protected by the fact of how the routing's routing is set up. Yes.

Exactly. So that's kind of like how, Kubernetes also works. So based on a lot of routing rules and so on within their systems. So in a Kubernetes kind of a this is easier to manage because you can have different namespaces where you operate your dev code, your staging, and your production code, and so on. And it's in each of these different namespaces, you can switch on and off certain routing rules and policies so that you can achieve achieve this in an easier way in in Kubernetes like environments.

That's great. Yeah. Yeah. I also agree. You know, that's a really good way to go about it because I don't know how many times when I've been developing something, you know, I've got the authorized attribute on it to make sure that, you know, the person coming in is authorized.

But for my testing, I comment that out so I don't have to worry about that. And it's like, okay. I gotta remember to to re uncomment that once I once I deploy. So it's always been a a real worry, in doing something like that. Moving it outside of that, definitely makes sense.

Yeah. Okay. So we've got the basic knowledge about securing your microservices. One thing I think that's really key would be now you've got it all in place. Do you think everything's working?

How do you go about testing it? Uh-huh. Yeah. Tricky question. So, it's basically, again, you know, there there are several things to consider when you're securing it.

So so one is in a testing kind of an environment, you need to find ways to mock your microservices, to mock mock your services. So there are various levels of testing you do. You do unit testing. And in that kind of a case, you you are mostly focused on mocking the dependent microservices and so on. So in that case, you basically, mock the stuff as much as possible and focus on the dependent unit that you want to test.

And then you go into the next level of integration testing where you kind of need these dependent services. So again, like you said, security context can be switched on and off, through some, tricks, I would say, by, you know, bypassing several layers using the routing protocols and so on. So that would be one way of getting around security. But when it comes to integration and end to end testing, it's basically right? I don't see any differences or, you know, any any things that are significantly different from how we would test an application.

Basically, we would be using the typical long running test, the the the continuous testing, and the tip typical security, stuff, sorry, the typical testing stuff that we will be using against any kind of application. Okay. So, I don't know. I mean, it all sounds really interesting. I think this is a a great topic.

I think I've I've learned a lot today dealing with some microservices and securing. What things have not have we not covered that, the users and our listeners should know about? So I think one of the things that we often forget is, like Joel was mentioning, like, we forget to think about security where it should be thought at about. So we may even think of authentication and authorization stuff right at the beginning of the project. But what's also important is that you, start practicing secure coding and designing an API guidelines as well, when you are starting a micro service project.

So this basically includes, you know, testing your code, for security, bugs and so on. So there are different kinds of tools that we talk about in the book. How how you can write secure code, basically. Because now if you if you look at any security system, any architecture, the the strength of the security of this architecture is only as much as your weakest point. So you may have all of the fantastic security layers that are required with, you know, service mesh or IP gateways or whatever.

But if you have a pretty basic security bug in your code, that's how low your security would fall. Because if someone can get through that, that means all of the other layers that you have on top of it, you know, they're useless. So your security is only as strong as a weaker security bug that you have in your system. So that's the tricky point when it comes to security. So it's very important to think about, you know, security even at the code level and even at the API design level.

So there are, you know, various, tools available for testing, checking your code for security loopholes, but not only your code, even your API designs, your interfaces. So there are tools out there, that look at your API design and tell you, how secure they are. Right? And so on. So Are there are there tools you would recommend?

Yeah. So we we have come across something called an API security dot I o. So that's this is basically for, REST API design. So if you go to API security dot I o, you will see how you can submit your REST API specification. So rest APIs are defined in what we call an open API specification mostly.

So you can submit your open API specification of your API, and it will give you a score. It will scan your spec and tell you how secure it is. And it will also give you recommendations on saying, you know, these are some of the improvements that you can do to your interface and so on. So I think these are some areas that people, you know, don't think about much in terms of securing their services. That's awesome.

That's awesome. Anything else we should know? No. I think we've covered it. So we we so Prabhat initially mentioned how the book is structured.

We talk about edge security. We talk about service to service security. And when we, of course, in the book, we talk about these kinds of secure coding practices and guidelines. So I think all of these combined should give you a good security practice and an infrastructure. That's great, Juan.

Yeah. Really good to have you on today. Yeah. Thanks. It looks like we, lost Prabhavath.

He must have lost his connection or something happened there. So he's not with us anymore. So but if there's nothing else, I think we should move on to picks. So my pick last week was, you know, my new VR headset. And so I've been using it this week and playing lots of games and apps and checking things out.

And one thing that I really think that I like about that I picked up is the elite strap. So it comes with a strap that's kind of a basic fabric strap that covers over the top of your head and then around the sides, but the pressure points are a little bit off. So I picked up the Quest 2 Elite strap, and it is is it's really nice because it puts the pressure point on the back of your head, and it really kinda secures the headset, makes it more stable, and makes it a lot more comfortable. Now I only got the Elite Strap. I didn't get the package where you get the strap and the battery and and a case.

I don't think the battery option is really that useful unless you really want that portability. But because you can just plug in and then any old USB battery pack into the side and get a lot more batteries, you know, length out of it. If you go with an external battery pack that's not the one that's built into the in the headset. So my pick this week is the Quest 2 Elite Strap. What's your pick, Joel?

Oh, that's great, Sean. Yeah. So as you know, I'm trying to get a couple of my bicycles ready for winter here in Minnesota. And last week, I had a recommendation for a person who has this wonderful website reviewing just the different levels of tires, what kind of riding you're gonna do. If you're gonna be riding on some dry paved tar, you don't want something too big as spikes because we'll actually tear the studs out.

If you're riding on snowier stuff, you need some more tread. So anyways, I figured out I'm gonna be riding occasionally paved occasionally shoveled trails. So there's gonna be generally some snow cover on them as well as gravel roads and off road. And so what I ordered and just showed up between when I talked last time in this show is the Schwalbe Ice Biker Pro for 20 niners. So I'm getting my mountain bike ready to be a commuter and, just kinda riding for the fun of being outdoors bike.

So I'll put a link in there to those tires. Those are the ones these are a pretty aggressive tread, so they're not meant for daily commuting on, plowed or shoveled roads. The spikes are too big and would tear out. These are meant for a little bit more kinda trail conditions and all. So, hopefully, I'll have this completely ready before our real snow hits.

We're supposed to get up to 50, I think, on Tuesday Wednesday. So I think all the snow that we got too early is gonna be gone. So our real snow typically comes in more like middle of November here. So I Yeah. If I had never heard, I should be ready for it.

Yeah. We've warmed up too. You know, we were we got down to about 10 degrees here about in this last weekend. But, yeah. But, we finally got back up into the fifties during the during the the daytime.

So, Yeah. So but, again, yep, mid November is when we really start cooling down. Right. Right. Yep.

Yep. Feeling ready. Alright. So, Nuwan, we did put a a link to your book in the show notes. So if people wanna check out your book, they can look at the show notes, and they can look at your book.

Is there something else that you would like to let our listeners know about that interests you these days? Well, nothing much. But one thing, in in the context of security again and APIs, I think the OAuth 2 dot one specification is is being talked talked about. There's a draft already, and it's being talked about. So I think we are having our next IEM meet up in in Silicon Valley.

So Prabhat is basically running that show. So, there's, someone who's leading the spec who's gonna be coming and talking about it. So I think that's gonna be pretty interesting, even given the context, that we are walking into, microservices and so on. So I think that's that would be something something interesting for for users interested in in this topic. Awesome.

Awesome. Well, thanks for coming and, talking to us today about microservices security. I I I thought it was a really good discussion. We I think I I learned a lot. So thank you.

Yeah. And thank you for having, having me and Prabhat as well. Unfortunately, he's having some trouble with his connection. So thank you for having the both of us, and it's it's been a real pleasure. Yeah.

And you want if if people want to, reach you or just get in touch with you, what are some of the best ways they could do that? So Twitter is, I think, mine and Prabhat both preferences. So Nuwandias and u w a n d I a s is my Twitter handle. And for Prabhat, it's just, Prabhat, p r a b a t h. So you can reach us through that.

Right? Yeah. That's great. And if our listeners wanna reach out to the show, they wanna get in touch with me. They can also find me on Twitter.

I am at.netsuperhero. Thanks, everybody, and we'll catch everybody on the next episode of adventures in dot net.