Security Patterns for Microservice Architectures

i am delighted to have my good friend matt rabel with us here to talk about security in microservices i want to remind you we do have a slack channel dedicated just this presentation so go ahead and click join the discussion and when matt is done we will have everybody head on over to the zoom q a area if you have additional questions that you'd like to ask and interact with the one and only matt rabel so without further ado i will turn it over to matt matt great to have you here this morning thanks friend thank you happy to be here so one of the things i've learned in my last years as a developer advocate is you really need a good youtube thumbnail for a talk and so these talks are going to be published i think on spring spring1.io after it so i want to have some good like right that you can use so i'm going to start with that and then i'll go ahead and share my screen here and start the presentation so welcome to security patterns for microservice architectures my name is matt rabel i'm hick from the styx i grew up in the backwoods of montana with no electricity and no running water had to walk two miles to the bus stop every day and yes it felt like it was uphill both ways but luckily my dad had a generator got some computers going and uh here i am today so i live in denver colorado with my beautiful wife trish my awesome kids abby and jack you can tell this photo's kind of dated since jack is taller than all of us now i drive i also have a middle child his name is jefe he's a 1966 volkswagen bus and i have an expensive obsession with classic volkswagens you can see the synchro westy on the left there as well so today we're talking about microservices and in particular security but before we get into that one of the things i just want to mention is there's been a fair amount of you know talk lately especially in the java ecosystem and at conferences that everyone uses microservices and there's also a movement where people are saying maybe we don't need microservices like why are we just doing this for the sake of microservices and it's a trendy topic and for good reason this is why this is from chris richardson he's a good friend of mine an expert on microservices he says if you're developing a large and complex application you need to deliver it rapidly then the microservices architecture is often a good choice so then you might ask why this talk why security patterns for microservices so the information on security patterns for microservices is just limited so chris richardson put together microservices.io and if you go there and look there's a number of security or there's a number of just patterns for microservices that you can kind of pick and choose which ones you want to use and so i scrolled to the bottom and i found for security just one pattern and that was access token so what i decided was you know i would come to the rescue and i would give you 11 different patterns for microservices security so one is to be secure by design two is to scan your dependencies three https obviously i shouldn't read all of these but you can see we're going to talk a bit about oauth and open id connect how to protect your secrets verifying security and then we'll get into containers with docker using time-based security kubernetes and your cluster security so secure code is the best code secure by design means that you bake security into your software design from the beginning and this book by you'll see there three dans is one that i highly recommend i wrote a review for it on my blog and it really shows how you know if you bake security in to the beginning you'll really save yourselves a lot of headache down the road so if you have user input one of the most important things to do is sanitize that input and remove malicious characters so i talked to my good friend rob winch and asked what he thought of removing malicious characters so rob is the lead of the spring security project which you probably know and widely considered a security expert and you'll notice what he says here is it makes sense to design your code to be security from the beginning but removing malicious characters is tricky at best and he basically says what's more practical is figuring out the context that you're trying to remove those characters and maybe just encode them instead well-designed software architecture is important as engineers we're taught early on the importance of well-designed software and architectures you study it in school you take pride in it you read books on it and design is a natural part of building software so well-known security threats should drive decisions in security architectures reusable techniques and patterns provide solutions for enforcing the necessary authentication authorization confidentiality data integrity and availability even when the system is under attack so you might ask what about owasp if you haven't heard of owasp it's the open web application security project it's a non-profit foundation that works to improve the security of software they're one of the most widely used sources on the web for developers and technologists to secure the web they provided an encourage like tools and resources community and networking as well as education and training however according to johnny christmas a well-known hacker the owasp top 10 hasn't really changed much in the last 10 years that basically means that even though we've given all these guidance to developers they're not just listing or maybe we have new developers coming on board or whatnot anyway we continue to repeat the same mistakes that have exposed systems for a decade now and so this is a quote i got from info cube podcast if you're in web security i highly recommend it it's really good and i really like it this is why security precautions need to be baked into your architecture because you don't want the ops top 10 to you know infect your company or be noted for that so secure by design like i said it's a great book and i like to show developers how you might bake in security by default so they show you how you can develop a basic user object that displays a username and shows that on a web page and so i do want to let you know that all the code in these slides is directly from the book there is one bug in there and i'll point it out but it just might not be necessary but it's still from the book so i didn't change it so if you start out with this user class and you just displayed that username obviously if you put any sort of malicious characters in there a script tag or something like that it just renders around the webpage depending on you know what framework you're using to render that so you want to do a little bit better than that you want to basically you know strip out xss characters so you can fix this with input validation and sanitation so this code is still problematic though right it's it's verifying that the id and the username are not null so that's good when it comes in and then you'll see it does the not null again so that's one of the things that people pointed out to me that hey why is it doing it twice well you know maybe you don't need that this dot id line but then the validate for xss is really good right because you're stripping out the characters or just validating that it meets the criteria but the problem is developers need to be thinking about security vulnerabilities right they'll need to know about that validate for xss method and when they should use it they need to be security experts and it assumes that the person writing the code has thought of every potential weakness that might occur at an hour in the future so that's not great what we can do is actually instead of just having string or username as a string we can use username as a class so you'll see in this example we have all the validation rules baked in we have the minimum the maximum the valid characters and then we can go ahead and you know do the validation when we create the object itself and so that encapsulates all the security concerns and the end developer doesn't really need to know about it as much here's a refactored version of that you're just passing in the username itself and all that will be validated before it even you know gets to setting the local methods so writing and shipping secure code is going to become more important important as we put software in robots and embedded devices because right now we might not be worried about vulnerabilities as much you know we use the latest versions of spring spring boot so we know there's no issues but at the same time if you put that into a device that never gets updated and can't update itself then you're going to want to bake in security right away so number two is to scan your dependencies third-party dependencies make up eighty percent of the code you deploy to production that's just a wag that's not like an actual specific one i'm sure it's different for different applications but many of the libraries we use to develop software depends on other libraries right we leverage spring we leverage spring boot we leverage spring security we have 10 or 20 lines of code that use those and there's really you know not as much code that we need to write ourselves but transitive dependencies can lead to a large chain of dependency especially for large apps and some of those might have security vulnerabilities so you can use a scanning program on your source code to identify vulnerable dependencies but you should use or you should scan for dependencies in your deployment pipeline right as you're going to production and in your primary line of code and in your tagged releases because you want to know if that production version actually has you know issues in there so maybe a cron job on a nightly basis to make sure and scan the code for your production this is a great presentation that rob winch recommended uh the application patching manifesto by jeremy long it's an excellent presentation and a few takeaways that he has from the talk is that 25 of projects don't report security issues and the majority only add release notes and only 10 actually report a cve so in short use tools to prioritize but always update your dependencies because chances are you know it's not reported as a security vulnerability even though it is so there's a youtube link on the bottom if you'd like to watch that one of the best ways that i've seen to do it if you're a github user in particular is use dependabot to provide automated updates via pull requests and what i've noticed is i work on a fair amount of javascript projects and in those projects the tradition is to use ranges for versions right it says you know major minor patch and if there's a patch release then go ahead and release that but in my experience i've had to actually change it so it doesn't use ranges and then the problem is you get a whole bunch of dependent pot requests because it just upgrades the patch release but i think it's better to lock down your versions in java maven gradle like they support ranges but we just don't use them because we know even though developers might release a patch release that doesn't mean it actually doesn't break something else so here's an example of depend about actually checking for an update right it pulls down your dependency files looks for any outdated or insecure dependencies and then it opens a pull request and so the nice thing about this is you're still in control on whether you want to actually merge this or not um you hit review and merge and then you check that your test pass and all that so it's pretty easy to do but like i said if you're using a package.json or you're using fixed versions especially in the javascript world you might have to be you know approving pull requests a fair amount and i do believe there's a way to automate this so if the tests pass it'll actually just merge it right in but i don't know if you really want to do that there's other more full-featured solutions for instance sneak snipe snick all kinds of different pronunciations there and jfrog x-ray so if you want to you know pay someone maybe have some more robust features maybe have the automatic merging and stuff like that take a look at those number three is to use https everywhere even for static sites so if you have an http connection change it to an https one make sure all aspects of your workflow from maven repositories to xsds and xml files refer to https uris and https has an official name called transport layer security or tls people used to call it ssl but that's deprecated in favor of tls and it's designed to ensure privacy and data integrity between computer applications so how https dot works is an excellent site for learning more about https you can see here we got the pink elephant and then we got the the cat the certificate and the computer and they're basically talking about why we need https for a few reasons and then it goes into you know this dog sending a message to the bird and then you got the evil crab getting in there and basically manipulating the data that's sent across and so it can become an evil message or become manipulated right across the wire so https is actually dead easy and dead simple these days this is a website from troy hunt where he basically shows you how to add https for free with cloudflare and he's got a bunch of really short videos that show you how to do that so there's really no excuse why you shouldn't be using https you should use it for static sites as well so this is a fun tweet from this guy that says basically you know i have this website that you can attack and please you know i bet you can't find any issues and troy hunt says great i'll go ahead and do that and so on his website he has videos of him doing the attack and what it shows is that really it's not so much about the website as the end destination it's really about where you're coming from so if i'm at home and i have centurylink as my provider and centurylink decides that they want to put javascript in my outgoing response so they can serve up some ads they can do that if it's an http connection if you're at a hotel or you're at an airport which is rare these days but still it could happen they can do the same thing so by having https it ensures that that data didn't get manipulated as it goes across the wire and so with http that can happen even if you're just coming from you know your house and not you know it doesn't really matter what the end destination is if you use https you'll need a certificate it's a driver's license of sorts and serves two functions it grants permission to use encrypted communication via public key infrastructure or pki and also authenticates the identity of the certificate holder so you can get free certificates from let's encrypt and you can use its api to automate renewing them from a recent info cue article by sergio de simone i wanted to quote a little bit of the history of let's encrypt so let's encrypt launched on april 12 2016 and somehow transform the internet by making a costly and lengthy process such as using https through an x509 certificate into a straightforward free widely available service recently the organization announced it has issued 1 billion certificates overall since its foundation and is estimated that let's encrypt double the internet's percentage of secure websites so nice work let's encrypt so let's encrypt recommends use certbot to obtain and renew your certificate so certbot is a free open source software tool for automatically using let's encrypt certificates on manually administered websites to enable https so the eff the electronic frontier foundation created and maintains certbot and so if you go to the cert bot website it basically lets you choose your web server and system then provides instructions for automating certificate generation renewal for example here's instructions for ubuntu and nginx right you'll shhh into your server you'll add the certbot ppa and then you'll install certbot and then you can either get and install your certificates or just get a certificate and then you can go ahead and test that automatic renewal and then you can use a site like ssl labs to confirm that your cert bot works and you're using the top of the line encryption on your website so you might ask why do we need https insider network if we you know have microservices that talk to each other and we're not hosting in the cloud we're hosting in our data center why do we need https between those services it's an excellent question it's good to protect data you transmit because there may be threats from inside your network phishing and guessing people's credentials are incredibly effective techniques you can buy gigs and terabytes of username and password combinations on the dark web and basically the attacker can gain access to an in-network machine with administrative rights and wreak havoc so that's why you want to have it internally especially because like the fishing way of getting people's credentials is so widespread and so effective that a lot of security companies actually don't offer it because they know it's going to work right so be wary of that you might also ask about graphql right when we're talking in the notion of https well graphql uses http so you don't have to do much from a security perspective the biggest thing you'll need to do is keep your graphql server up to date because graphql relies on making post requests for everything and so your server is going to be responsible for input sanitization that's probably going to be provided by some sort of project with a graphql implementation so that's the most important thing there there's also our socket so our socket is next generation reactive layer fire application commun layer 5 application communication protocol for building today's modern cloud native and microservice applications you can tell i copied that off the website right that's a that's a marketing blurb if i've ever heard one so what does all that mean it basically means our socket has a reactive semantics built in so it can communicate back pressure to clients and provide more reliable communications so the r socket website can says implementations are available for java javascript go dot net c plus plus in kotlin and r socket is an application protocol providing reactive streams semantics over an asynchronous binary boundary so netify is one of the main companies behind our socket it's a cloud native application platform built on our socket and it dramatically reduces operational overhead and speeds development with ai driven management and reactive software components you can tell that's another marketing blurb so you can if you want to do our socket and you want to do secure our socket you can deploy on netify and they will provide that as one of the services but you can also use spring security 530 and higher it has full support for securing our socket applications and if you want to get started with our socket a little more about it i'd recommend you read this blog post from ben wilcock getting started with rsoc and spring boot server so number four use access and identity tokens so oauth 2.0 has been providing delegated authorization since 2012 and openid connect added federated that identity on top of oahu ii in 2014 so open id connect doesn't exist without oauth 2 a lot 2 can live standalone but it doesn't provide any identity it only provides authorization information so together they offer a standard spec you can write code against and have confidence that will work across identity providers so you could use octa my company for instance you could use a authorization server that you build with spring boot you could use someone like one login and that should all work so the spec also allows you to look up the identity of the user by sending an access token to a user info endpoint that's number five in this slide and then you can look up the uri for that endpoint using oidc's discovery which provides a standard way to basically figure out the endpoints that you need for oauth so you'll see number one that well-known open id configuration any issuer that you have from an identity provider you should be able to tack on that at the end of that issuer url and you will get all the different endpoints all the claims that are supported and things like that if you're communicating between microservices you can use oauth 2.0 client credentials flow to implement server-to-server communication and the diagram below the api client is one server and they are so you can see you know we're getting that token from the authorization server and then we're using that token in an authorization header with a prefix of bearer to talk to that api service and if you're using a lot too to secure your services you're using an authorization server and the typical setup is a many-to-one relationship where you have many microservices talking to one authorization server there's some pros and cons of that the pros our services can use access tokens to talk to any of the internal services there's a single place to look for all the definitions it's easier to manage and it's typically a little faster the cons opens you up to rogue services if someone just adds a new service to that authorization server they register it and it's not you know up to snuff and it causes security issues then you know you're open to attack there but again that's internal right if one service token is compromised all services are at risk and there's kind of vague service boundaries so one way to mitigate that is a one-to-one pattern where you have authorization servers for each of your microservices if they need to talk to each other they need to register before trusting and so the pros are there's cleanly defined security boundaries it's a little slower as a con and it's hard to manage because there's more you know pieces in place i also want to mention while we're talking about oauth and openid connect json web tokens or jwt so they have become very popular in the last several years and they've also come under fire this is mostly because what developers try to do is they try to build a stateless architecture using jwts and putting all the information they need to put including the state into that jwt and so you know there's another thing that's come along that's kind of made things better and that's facetto so pasetto is json web tokens the good parts so this is a doctored image if you've heard javascript the good parts there's a big book there's a small book and facetos basically you know the good parts of jwt and so one of the main selling points of jwts is cryptographic signatures and because jwts are cryptographically signed a receiving party can verify that the jwt is valid and trusted but you know it's been doing this for the last 20 years and it's pretty much baked into every web framework that exists is plain old sanction cookies they have cryptographic signatures the web server can validate them all that kind of stuff well so my uh my co-worker randall wrote this great blog post on why jwt suck as what has session token so basically you know the secure way to do it is use http only cookies you know and uh and just use the way that our web frameworks have allowed us to keep sessions going and uh jwts they're great but don't use them as session tokens use them as you know something that contains the information about authorization and not so much state so facetto stands for platform agnostic security tokens it's everything you love about jose jose stands for jwt jwe and jws which is you know jwe's encryption jws's signature without any of the many design deficits that plagued the jose stannics so jose stands for javascript object signing and encryption long story short is that pasetto tokens isn't as easy as it sounds if you want to write your own security maybe your own authorization server then it's probably possible but if you're going to use a well-known cloud provider like us chances are we don't support settle yet we do have a jay pacetto library out there if you google for jay pacetto you can find a java library that will allow you to produce and valid validate uh you know set of tokens so the next one is five encrypt and protect secrets so when you develop microservices that talk to authors in microservices probably have secrets that they use for authentication so these secrets might be an api key can be a client secret or it can be credentials for basic authentication the number one rule for secrets is don't check them into source control there's some great tools out there i think there's a github action called get help guardian or something like that there's a tool that we use in our repos that will actually send you an email and fail to build if there's a secret in a pull request so even if you develop code in a private repository it's a nasty habit and if you're working on production code it's likely to cause trouble so make sure you don't check secrets in the source control so the first step to being more secure secrets is store them in environment variables but this is only the beginning you should do your best to encrypt your secrets so in the java world i'm most familiar with hashicorp vault and it has spring support via spring vault and there's also azure's key vault which is similar to amazon's key management service for kms and so if you're interested in learning how to use spring cloud config and vault with uh spring boot we wrote a blog post on that published it earlier this year it's uh very comprehensive shows you how to encrypt them how to get them out and works really nicely with spring cloud config so my co-worker randall is a big fan of amazon kms and their key management service and the way it works is you generate a master key using kms and each time you want to encrypt data you ask aws to generate a new data key for you and the data key is a unique encryption key aws generates for each piece of data you need to encrypt and then you encrypt your data using the data key and amazon will then encrypt the data key using the master key and that results in you know the final encrypted message so it works really nice really fast and uh you know like most things amazon it's uh you know pay by usage number six verify security with delivery pipelines so dependency and container scanning should be part of your source control monitoring system but you should also perform tests when executing your ci ocd pipelines so devsecops is the term that doesn't really roll off the tongue right devops does that sounds pretty good devsecops anyway it's the term that many recommend instead of devops to emphasize the need to build security into devops initiatives i wish it rolled off the tiny gear that's all so basically devsecops is injecting security into your cd pipelines so this is a great article called beyond ci cd how continuous hacking of docker containers and pipeline driven security keeps wygreen secure so why green energy fund is a financing corporation that provides property assessed clean energy financing to residential and commercial properties for energy efficient projects and basically this article is from zac arnold and austin adams and they recommend the following you create a white list of your doctor images whitelist probably isn't the right term accepted list of base images pull only cryptographically signed base images sign the metadata of a published image cryptographically use only linux distros that verify the integrity of the package when pulling third-party dependencies only allow https there's even you know plugins to do that now i know spring uses one on all their repositories and don't allow the program to build images whose docker file specifies a sensitive host path as a volume map so what about the code they also talk about that in the article run static code analysis for known vulnerabilities run automated dependency checkers to ensure latest versions spin up your containers and run automated penetration penetration testing bots on the running containers so they recommend za proxy for this this is a you know from owasp zed attack proxy and what it allows you to do is record a session you can basically if you have a public website that doesn't really have you know much security or secure sections to it you can just give it a url and it'll crawl that website and try to find things but if you have an authenticated section of your website what you can do is you basically set it up so it proxies through your browser your browser goes through that attack proxy and it'll record all your actions all the urls and then when you play it back it'll find all the forms and it'll try to enter malicious characters and basically hack your website so it's really nice uh works pretty well i've used it several times number seven is to slow down hackers if someone tries to hack your apis with hundreds of gigs of username and password combinations it could take a while for them to authenticate successfully so if you can detect this attack and slow them down it's likely the attacker will go away if they can do you know three requests a second versus one request every 20 seconds it's simply not worth their time they're just going to go somewhere else and you can implement rate limiting in your code often with an open source library or in your api gateway i'm sure there are other options but these are usually the most straightforward implement and most sas apis use rate limiting to protect customer abuse so we at octa have api rate limits as well as email rate limits to help protect against denial of service attacks number eight use docker rootless mode so in docker 1903 they introduced an experimental rootless docker mode that helps mitigate vulnerabilities by hardening the docker game so developers design this feature to reduce the security footprint of the docker daemon to expose docker capabilities to systems where users cannot gain root privileges so if you're running docker demons in production that seems kind of strange definitely something you should look into though but i think most people are probably using kubernetes to run their docker containers so in that case you'll need to configure the run as user in your pod security policy number nine so the idea behind timepay security is that your system is never fully secure someone's going to break in preventing intruders is only part of hardening the system detection and reaction are essential too so using multi-factor authentication can be a way to slow down intruders and it also helps to detect when someone with elevated privileges logs into a critical server not that mfa provides that but you should monitor that so if you have something like a domain controller that controls network traffic and someone logs in as administrator to that you should probably alert the other administrators on the team to let them know that this privileged access actually happened and so you know you're not actually looking for anomalies you're looking for people doing things with elevated access and so randall has a great thought on nfa and it's funny because basically security experts and people that run security a lot of companies just love mfa because it makes their job so much easier here but as users are often like frustrated right they're like oh my phone's way over there i gotta go get it just log into this website so you know it's slow it's annoying it's frustrating can be pointless but at the same time you can implement adaptive mfa and a lot of companies provide this where you will actually detect where the user is what they're doing if they've had any strange you know things happen lately like they just logged in from california and now they're in london five minutes later like that's not possible right so adaptive mfa is a little smarter and it'll allow you to not prompt the user for mfa if they're just doing you know regular patterns so he's got a blog post on that if you wanted to check it out number 10 scan docker and kubernetes configurations so docker images are very popular in microservice architectures and our friends at snike sneak published 10 docker image security best practices it repeats some of the things i mentioned but i'll summarize them here anyway so the first one is you know having that accepted list of docker images there's the least privileged user to create a dedicated user and groupon image and you know don't run everything as root uh sign and verify your image to mitigate those man in the middle of the text fixed monitor for open source vulnerabilities and then you'll see they even have a cool cli where you can run snick test or snick monitor and you'll know if there's issues with any of the containers you're using leaking sensitive information to docker so follow these guidelines using multi-stage build use the docker secrets feature and use a docker ignore file to you know ignore files that shouldn't be copied in there especially ones with secrets use fixed tags use copy instead of add use multi-stage builds and use a winter so paddle winter is one that will basically you can run and see if there's any issues in your docker files i also wanted to point out this research on the top five docker vulnerabilities that you should know and the reason i'm not going to drill into this and actually list them is because they're kind of low level and they really didn't pertain to me as a developer i think they're more like devops or devsecops but you can also scan your kubernetes configuration for vulnerabilities but there's much more than that so i'll cover kubernetes in the next section so if you're managing your production clusters and clouds you're probably aware of the four c's of cloud native security from kubernetes.io and that is each one of the four c's depend on the security of the squares in which they fit is nearly impossible to safeguard against poor security standards in cloud containers and code by only addressing security at the code level however when you deal with these areas appropriately then adding security to your code augments an already strong code base so the kubernetes blog has a detailed post from andrew martin titled 11 ways not to get hacked so ander offers these tips to harden your clusters and increase their resilience if a hacker compromises them so this blog post is from july 2018 but not a whole lot has changed i do think there's a fair amount of hype around service message since 2018 but that hasn't made a huge difference so again he's saying use tls everywhere enable rbac do least privileges uh do audit logging he's a third-party auth provider you know someone like google or github or us separate and firewall your ncd cluster rotate your encryption keys use linux security features and the run a service mesh right that's the one at the end there and i just wanted to touch on that a bit more so a service mesh provides critical capabilities including service discovery load balancing encryption observability traceability right whole bunch of ilities you can do authentication and authorization via your service match and you can even support the circuit breaker pattern so in spring and spring cloud you might be familiar with using like histrix or doing communications with fane and doing a lot of that in code well with a service match you can kind of just let it handle all those retries and things so requests are routed between microservices through proxies and their own infrastructure layer and for this reason individual proxies that make up a service mesh are sometimes called side cars so in this diagram here it's the little blue thing on the side with the lines and they run alongside with each service rather than within them so running a service mesh like istio might allow you to offload your security to a shared battle-tested set of libraries still i don't know if it simplified the deployment of the next generation of network security that was a quote from the previous article so that was written in 2018 and you know it's uh i think for developers like we still like to kind of see the security in our code rather than on the service mesh but it's certainly something to consider and a pattern for microservices so i hope these security patterns have helped you become a more security conscious micro service developer it's interesting to me though that half of my list pertains to developers that write code on a day to day basis and then six through 10 seem to apply it to devops folks or rather dev seconds so since all these patterns are important considerations you should make sure to keep a close relationship with your developer and devsecops team and in fact if you're doing microservices right these people aren't on separate teams they're on the same product team that owns the microservice all the way from conception and ideas to production and monitoring and making sure it stays up and updating it so you know it's one of those things that if you're doing it wrong should be obvious put everyone together on the same team so function design with security in mind scan your code use tls use oidc because friends don't let friends write authentication plan for attacks and study time-based security my team also wrote a book on api security it's guide to building securing apis from the developer team at octa you can see we have a bunch of other information in there so it's pretty short on probably 120 150 pages i'd invite you to check out the octa developer blog we have a lot of security topics we post a lot of spring boot tutorials i posted one earlier this week that describes how to build an app with spring boot and kotlin and deploy it to heroku and use our octa add-on we also have a ton of them on progressive web applications angular react vue microservices and jhips are one of my favorite projects that allows you to generate a microservices architecture and we also have a youtube channel that's available at octadev as well youtube.com octadev we post a couple videos a week about these kind of topics and we've got a lot of subscribers there these days so a huge thanks to chris richardson and rob winch for their thorough reviews and detailed feedback on the blog post that backs up this actual talk and uh you know they are a real help on making that awesome so you can see the url at the bottom there microservice security patterns i think you can actually google microsoft security and it's number one so i got my seo research and keywords right because it's tough to get to number one on google so thanks for joining me today and listening to my talk if you want to keep in touch my blog is at raibledesigns.com you can see my summer adventures in montana on there i'm available on twitter at mrabel my direct messages are wide open my presentations are up on speaker deck at mrabel and i've already uploaded this one so if you want to go grab the slides you certainly could a lot of the code i published these days is on the developer so thanks for joining and may the auth be with you all right thank you so much matt i really appreciate it and i invite everybody here to click join the discussion and come on over and watch and have continue the conversation ask matt some questions in the zoom q and a and you know matt i have to say my son is 13 and almost the same height as me in fact we had this debate last night if he actually is now the same height i am and i do realize in the grand scheme of things he will be taller than me it's just a given it's just a matter of whether he's already there or not so i can absolutely relate with you there on the joys of parenting when they outgrow you apparently if you feed them they continue to grow who knew who knew well with that friends i invite you we're going to take a break go get yourself something drink my lovely wife christine brought me some caffeine so that should help my afternoon because we we still have a number of fantastic presentations on the way so get yourself a beverage hit the restroom stretch your legs grab a snack and we'll be back shortly with some more amazing content thank you [Music] you

Channel: SpringDeveloper

Views: 15,051

Rating: 4.9880953 out of 5

Keywords: Security, Serverless/Microservices

Id: s4wsqYaZJ2s

Length: 40min 29sec (2429 seconds)

Published: Fri Sep 25 2020