Securing Cloud Applications, the book, with Adib Saikali

Episode 231 · Wed, 08 Dec 2021 14:00:00 +0100 · 42:44 · SRT · archive.org · all Tanzu Talk

Well, I've been reading through a draft of your book, securing cloud applications. And, and you know, it's, it's a great, I like the way you lay out the you know, I, I mean, I mean, it's an obvious, well, it's one of those obvious things that's worth always being obvious about because one forgets it. And it's like, this is a security, like many technical things is a confusing topic. And the reason it's probably confusing is because you don't understand all the small little components it's made of. So when you get some mysterious error message and I, back when I programmed, I would get this and it says something about a certificate or something. And you're like, I have no idea what's happening. And then you're just like, as a developer, you're like, security is terrible. I don't like it. And so, you know, to, I, I would say, you know, that the developer experience or dev X, as people like to say that the developer experience of security is pretty awful still, it seems like. And, and my question to you is like, why, why, why is it so complicated? Why don't they just fix that? Like what, what's the deal? Well, I, I, I think that security is complicated because of all those little details. Like I personally would consider myself to have had a headstart on that. Cause in the nineties, when I was in university in the late nineties, a lot of my friends were like security geeks and, I would just read like a whole bunch of the books. I read like, you know, the Bruce, Bruce Schneider, Schneider's book, like, you know, the big thick one, like that explains all the algorithms. I was kind of cool and all of that. So over the years, I've always read security books regularly, but I cared more about application architecture. There was so much more, many more fun things as a developer to pay attention to. The other problem is that like security books and security content tends to assume, you know, a lot of math. And if you do, you really enjoy it. And it always, and if you, if you don't, and you're like, don't care about that math, then like it's mysterious. And, um, none of the settings make sense because it's a situation where you don't know that you

don't know something. So if you don't know that you don't know something, you don't even know that you need it. So, you know, my first bout of fighting with a security system was, I was doing a consulting project at a bank trying to connect to the mainframe with WebSphere MQ and my Java program wasn't connecting. And I had these mysterious error messages and it took me like, uh, I don't know. It took me to be like a week to debug it because I had to go buy a book on how TLS worked, read the book, find all of the debug arguments for the JVM to finally understand what were the Cypher suite settings that were required to make it work. And at the end of it, I was like, wow, that's really cool. I learned all the stuff. I'm like, and the other part of it was like, oh no, nobody at the bank will know how to do this. Like the average developer won't. So I think there's been a general lack of just teaching the basics. There are no, there aren't very many developer friendly security books that are treating the developer with respect. Yeah. Yeah. And, and it seems like, you know, reading, reading through, uh, through, through your book, you know, to your point, it's sort of like a lot of that, it's like describing a tool. A lot of the security stuff I encounter is describing how to use a security tool in the context of security rather than in the context of like, I'm doing an application. And, and I mean, the example you gave is, is, is a good one. It's just like, as an application developer, you're like, I just want to connect to a mainframe and like get some information or tell it to do something. And now I'm spending a week learning something else. And, and this, this something else isn't really, I mean that I, to be fair, I haven't really like looked at security stuff in a long time, but when I do look at it, it often seems like it's like security things are not necessarily like thinking in terms of a developer. Like, I mean, I'll give you a, an ancient example, right? Like I was just remembering as we, before we were recording that I, uh, this book you're

writing is a Manning is you're doing it with Manning. And I wrote a book with them that they decided not to publish about the, uh, Java authentication and authorization service. And I remember, I remember going through doing that and, and it was equally like just confounding like, like the way that it worked. And I remember using it and thinking like, I don't know if anyone who's, who wrote this, the jazz stuff, like actually wrote applications that work with it because it's a very, like, it's a very well, what is it? It's a very beautiful system, but then you're basically as, as an application developer, you're like, I want to log someone in and see if they can access the, the, the Jackson report. That's really all I want to do. Like, yeah, it is. And that, that particular API is super mysterious because there's no standard definitions of what terms mean in the industry. So like take the, something as a user. Oh, it's principle. It's a user. No, it's a, it's a system identifier. Like it's whatever who, who, you know, it's a subject, right. And it's a, there's a subject and an object and it's, it's, it's really, there isn't a consistent way to do it. Like, like some of my other security fights were literally like designing the security architecture of particular applications. So an application I worked on in the early days before, you know, the iPhone was like a mobile app. So you had these HP iPacks. I don't know if you remember those. Yeah. ECMCI card you put in the back of it. And then it was like a platform where you could build little apps to do things that people need to do in the field. Like you have a bunch of appliance repair technicians and you want to be able to say, Hey, there's a customer called in and we need to dispatch a tech to this location to fix an appliance. Right. And then whoever responds first gets to go do that, that repair. Right. And how do you, how do you like build a platform like that and isolate different companies, you know, apps from each other?

How do you get just the right apps to the devices, the right data to the devices? And so it was a lot of these types of app security architecture things where the security was part of the business requirements of the app. So you couldn't, you couldn't avoid thinking about it because you had these sophisticated ways of doing it. So that was like the second bout of, of like consecutively over a period of probably 10 years, I did that three times or three or four times for several applications, but had a complex application security requirement and boiled down to learning things like role-based access control and attribute-based access control. And boy, it was that hard because I'd be like searching online and like reading, reading like papers that PhD students were writing to try to decipher what this stuff was. And at the end of it, again, the same thing, like they're not really writing apps. They're, they're trying to prove that the security model is awesome for some reason. And I'm like, but I just want one user to share, to be able to share this data with that one without actually having to do it like 50 million times, like change 50 million settings. And it, it, it, it, it taught me a lot about like, like that security isn't one thing. There's different layers to security. And there are some things that I could use as building blocks as a developer. And what I have to know about those things is not how they work, but how to configure them. So like a good example of that would be like, okay, um, my customers in due diligence are asking, are all your communications secure? Sure. They're secure. Well, how are you securing them? Well, with TLS, well, what cipher suite are you using? Well, what's a cipher suite, right? Well, you need now need to know what the block encryption algorithm is. You need to know what the hash function that's being used is. Okay. What's a block encryption algorithm? What's a hash function, right? And, oh, look, this hash function has like 512, 384 and 256.

Well, which one should I use? I don't know. I'll just use 512. That sounds like more secure than. Right, right, right. And you're like, you're sitting there trying to make these decisions and, um, and, and you're, you just don't have the background. And that's what I found that because I was willing to read the math books, I developed a decent understanding of what these things are. And I'm like, I'm never going to implement the security libraries, but at least I know what the configuration settings do. Uh, and most of my colleagues weren't able to, didn't know that and couldn't debug anything because of that. Yeah. No, I, you, you, you, you, you raise a, another, I mean, another fun, slightly snarky thing is like, at some point, it's probably a bad idea to give configuration options that you should never use. Right. Like, and, and I, I mean, that happens in all aspects of programming and systems and stuff, but, and, and whatever, there's good reasons to do it. But, you know, I mean, it seems like, especially when it comes to security at some point, if there's like, you know, not good, if there, if anything, if any, like, uh, part of a system includes the word weak, it should probably just not exist. Right. Like it's, it should be called out of there. And I think, I think that that's an unfortunate, um, you're right about that, but I think the U S export policy had something to do with that. Oh yeah. I could see that. Yeah. Cause I remember like, like, so I started at university like in 1995, right. And, um, uh, at the university of Waterloo. And one of the cool books that was there was like a printout of PGP, like, uh, the PGP pretty good privacy email system. And, and you'll open up the book and it was just C code, like from beginning to end, because it was illegal to export strong cryptography out of the U S but the U S first amendment protects freedom of whatever. I said, which one is the amendment that says you can publish anything you want? Uh, I, I, as an American, I should know, but I forget. Whatever that one that says you have the freedom to say whatever you want. I think that's your, your first amendment rights.

Yeah. Yeah. Whatever it is. And so they're like, ah, the loophole is publish all the source code in book format. You can sell the book wherever you want because, well, you're not exporting software. It's speech. It's speech. Of course. It's speech. So all you have to do is like retype all of that and, and you would be, you'd be in good shape, right? You'd have a, you'd have a working thing. And I think that's why all these like kind of in quotes, weak security existed before, um, or weak defaults for all sorts of things. Yeah, yeah, yeah, no, that, that, that's a, that would make a lot of sense. So, so then the other thing I, I, well, first, why don't you introduce yourself? Oh, sure. Thanks. Um, so my name is Adip Saikali. I'm currently a principal solutions engineer with, uh, with VMware. My customers typically like to call me the code janitor, uh, because they, you know, over the past seven years, uh, that I've been with pivotal VMware, uh, I've been in, uh, situations where customers will say, here's a USB stick. We've got, you know, uh, three gigs of source code on here. It's this app makes us a billion dollars a year. We don't know what to do with it. We have a hundred developers. How do we make this app more cloud native? Right. And they're typically by the time I get a chance to look at it, they've already, uh, worked with two or three of the big solutions, uh, SIs, and they've made many attempts and tried many things. And I typically will say, great, let me read the source code first, and then I'll give you some recommendations. Um, and so this is why I get called the code janitor and, um, uh, typically, you know, I end up, uh, helping them delete a few hundred thousand lines of code, which makes me very happy. It gives me great pleasure to remove hundreds of thousands of lines of code from, uh, from applications. And inevitably, as part of that transformation, security pops up because, uh, they're like, we want to make things more secure. We have an infosec team that we need to present to what we're doing, how we're modernizing things. And that gets into a lot of like, oh, we're, we're confused. Uh, we have this app deployed to a thousand stores and we need to authenticate this API call.

How do we do it? Um, well, these are your three ways of doing it, but that kind of sounds hard. We don't want to do that. Well, okay. What would you like to do? Well, we're buying an API gateway. It's going to solve all our problems. It's going to cook us breakfast. Okay. Um, and so you end up with these types of situations where security becomes a blocker for evolution of the system. And a lot of the time, the software teams just need a little bit of help to do that. So, so that's, that's what I do. I spend my time doing that. And, um, I, I really decided to write this book, the securing cloud applications with Manning, uh, because it's the book I wish I had. Like if I had it, I would probably have spent, uh, I'm not kidding, at least 30 or 40 days of time with the family that I didn't because I was divulging some security issue. Yeah. Yeah. Yeah. Yeah. Yeah. No. And so, yeah, the, uh, the, uh, well, so, you know, in, in that, going from that situation where, where you're, you're janitorizing or whatever the verb for janitor is janitoring. Anyways, uh, so, you know, in, in our, in our world, our industry, there's this phrase dev sec ops, which is fine. And, and, uh, I think, I think maybe, I mean, we can get to this in a little bit, but maybe we've settled on what that means after like a couple of years of tossing things back and forth. But as, as you were explaining or kind of going over, you know, dealing with the mainframe and cleaning up this code and stuff, it was making me think. So in, in the DevOps world, when, when DevOps was evolving, there was first this notion of, let's call it the full stack engineer that the developer is going to be doing operations stuff. Right. And, and that they are, they should know about operations things now, because that's going to be part of their job. Cause you build it, you run it or whatever. And I think during that time, there were a lot of new tools, not only, you know, nowadays

DevOps is all about culture and process and things like that, which is fine. But back, back then it was just all tools. There was a bunch of tools and automation things. And that kind of comprised having developers or whoever be able to do DevOps stuff. And then eventually I think what, what DevOps more became was sort of like operations people should behave more like developers. Maybe they don't write code, but they will be doing things in a very developer oriented way. And then eventually you end up with like get ops, which is just like, you know, basically like operations being developer people, uh, all the way down to checking stuff in, except I don't think they have programs still, but whatever. And like, so I, you know, as I was reading through your book and, and, and you were talking just now, I was thinking like, so with dev sec ops, knowing that path of DevOps, like, are we, are we expecting developers to like get more knowledgeable about security, like be a full stack security? I don't even know what the phrase would be. Or are we sort of like expecting security people to like make being secure easier for developers? Uh, that's a, that's a really good question. And the, the answer, my answer to it is no, I don't expect developers to become, um, like, uh, the equivalent of a full stack developer for security. What I think a, uh, is, is more achievable and reasonable goal is to basically have developers learn the very basics that are needed to more effectively work with security professionals. So in a lot of my, uh, uh, adventures over the years with customers, um, I get to spend a lot of time with info sec teams and info sec teams are always paranoid that the developers are going to do something they're not supposed to do. And so in order to deal with that, there's a lot of, um, uh, there's a lot of reviews that people do. And because of the, a lot of the reviews that happen, um, uh, it becomes one of these things

where the auditors need to find something wrong that you did, the inspectors, so to speak. Otherwise it looks like they're not doing their job. And, and then you end up with really bizarre rules that kind of were written in the past and don't make sense. And developers don't know how to push back on those because they're, they don't have the, they don't feel like they have the background. And eventually the people that are doing the check boxing with the security in a large enough corporation, they're just kind of doing it because that's what they've been told to do. And it's there, there's like, they can't change the process themselves. It just gets weird. So what I'm, what I, I think of it like this, um, a security event could end the company out of existence in 2021, right? It's a large enough security event company will go bankrupt potentially. So CEOs are basically saying, great, I'm going to hire a chief information security officer. I'm going to empower that CISO to, uh, to make whatever changes are needed to make sure we don't, you know, we don't get packed and all this type of stuff, but what does that mean? What does this focus on extra security mean for you as a developer? In my opinion, it means two things. Number one, you're expected to use all the security features in the technology that you're using, right? So if there's a checkbox to enable more security in a product that you're using, you should do that, right? And you shouldn't just like say, ah, I don't know how to configure it. So I'm not going to do that. But in order to configure it, you need to understand some basic general security concepts. Otherwise, if you don't understand the basic security concepts, what will happen is you will go into Stack Overflow on the Google and be like, how do I configure a mutual TLS in Spring Boot? Boom. You're going to end up with like a hundred blog posts. Someone will be out of date, right? You'll copy and paste something. It works. And you're like, I'm done. And then your security people audit it. They kind of, you know, lose a few hairs in the process. You go like, what is wrong with developers?

Like, clearly. Yeah. Yeah. So there's that part of it. And so developers invest a lot of time, like, I want to learn, you know, Spring Security. I want to learn, you know, some security framework. But they don't know the basic concepts below it. So if they know enough of the basic concepts, they can better collaborate with security professionals. They can better read the corporate security guidance and follow it. The other side of it is around process. I think that's where DevSecOps happens. And I kind of think about that as there's the industry kind of best practices for DevSecOps, whatever they are. And within your company, you need to follow whatever your company's process is. As a developer, you don't need to define what that process is. You need to be a good citizen and lead by example and be like, yes, I did do all the things that the DevSecOps process requested me to do. And not only that, I noticed where the friction was. And I went and I talked to the InfoSec team that owns whatever aspects of that DevSecOps process. And I came to them with practical suggestions for how they can make me more productive. So really moving away from security is a department of no. Right. Because they're used to assuming the developers don't know what they're talking about. To the security being a partner that we can collaborate with. And there's more trust between the security teams and the development teams. Because the development teams can talk to them in their language. Yeah. Yeah. No, that's, you know, I feel like, you know, you've chosen two roles in IT and described like almost every single non-technology problem that occurs. Right. Where you have, you have, let's call it N plus one groups of people that have to coordinate to make a, as we would say, an outcome happen.

Right. To, to, to just, you know, do something. And those, it, it, it can seem like from, from a cynical outside observer standpoint that those two T, those N plus one teams exist to make sure that the other teams don't actually do anything. Right. And, and like, and, and even worse that they like, that they have a poor opinion of the capabilities and even intelligence of the other teams. Right. Like, and instead of, instead of, I think more of the collaborative, maybe even nurturing thing is to be like, well, some people know some things and other people don't know other things. And the reason that, the reason that we're separate groups is that we like, and this is where like, you know, a lot of like DevOps culture stuff gets a little, like needs a lot of footnotes because, because you use a word like, you know, people specialize in things. Right. We can't, we can't all know everything. So you've got to divide things up. And so to your point, it'd be great if these N plus one teams like helped each other. And yeah, I mean, no, it's true. And it's, I love that you brought up the word specialist, partly because there was like in my, early in my career, there was this blog post I read before blogs were a thing. People just had personal websites, I guess. It was a blog post by Scott Ambler called the generalizing specialist. I don't know if you've ever read that. This would have been published in the nineties or maybe long ago. Yeah. Like the early, early two thousands. And back when there were like, you know, software magazines that you would actually buy in the store, like Dr. Dogs and, you know, go to the store and buy, buy, buy a computer magazine. And, and what that article argued was that it was brilliant. It basically said, if you have a team of specialists, they can't get anything done because they can't talk to each other because you're the database specialist, you're the Java specialist, right? They talk past each other. Right. And if you have a team of, of generalists, you won't get anything done because you don't have enough skill.

So it was kind of saying, well, we should actually have teams where we have generalizing specialists and a generalizing specialist was defined, but was defined by Scott as somebody who was like a, a Jack of all trades, master of a few. And the idea was that if you had that mix of people on the team, right. You would actually be able to collaborate effectively while still having the specialist depth to get stuff done. I guess nowadays we would probably call that a balance team, right? Yeah, yeah, yeah. Yeah. You know, so that's a, I mean, yeah, obviously it applies to like security, but it applies to things in general that, that is, I don't know which comes first, but you know, a while ago you're saying one of the issues that one can have with security, especially developers is like, you know, the not, not knowing what you don't know. And those, those, you don't even know what to look for. And it's almost like, if you, if you have relatively deep knowledge on at least two subject matter areas, you sort of learn this thing of like, oh, I should ask and find things I don't know. Right. Like, even if you don't know a topic, at least, you know, enough to, as, as you, you do in the book, like to say like, all right, what are like the atomic units of this stuff? Like what's the foundation that I have to know in order to figure out how to configure my certificate to attach to the mainframe and like knowing that you should spend time to learn, do that kind of stuff seems like, again, I don't know if that comes like, that's how you get to have that second specialization, but it's definitely, uh, that's almost the generalist part of it. Right. Is to be able to break out of your own little specialization, but even, even, you know, what, what, uh, what I'm, uh, rambling towards saying is like, even knowing that you can do that is, is, is, is a, is a valuable, uh, piece of knowledge to have. So we keep alluding to it. What are those atomic units that, you know, that you go over that you want, you don't have to detail every single one of them, but like, what are, what are these basic things that

you think developers should start with and they don't have to master them, but if they know about them, they can, they can figure things out well enough. Yeah. You know, that's, that's a, that's a great question. And, um, I think what it boils down to is, uh, is that like fundamentally you need to get comfortable with TLS and mutual TLS because it's everywhere. Right. So you need to understand like, what's a certificate, what's a certificate chain? How do I get a certificate? How do I revoke a certificate? Right. There's how, what are the limitations of digital certificates? Right. Because like I interview a lot of people as you know, when they apply to VMware and one of my favorite questions is have you ever got yourself an SSL certificate, what's the process? And all I'm looking for is I create it on my computer. I create a signing request. I send it to some CA certificate authority and they send me back a certificate, right? Just that you don't need to tell me the command line. Don't need to tell me, but just, it tells me that you actually know, like you've done it once before, even if you faked it on your laptop with, you know, self-signed cert, but like knowing what that is. So it's like, how do I get a developer to the point where they're comfortable setting up something like mutual TLS in a Spring Boot application? What are the things you need to know? So working backward from that, there's a whole bunch of cryptography that, that you need to understand, like what's a TLS cipher suite? Why are there three versions of TLS? And what is a TLS handshake? So I don't need you to know the protocol, but I have to teach you like hash functions and AES and a variety of these things. And so that kind of, once you have that mutual, once you know what mutual TLS is all about and you're comfortable with that, then the next problem you're going to tackle as a developer is something like, how do I securely handle secrets? Okay. I have a password to the database. I have an API key. Where do I store that? And there you run into the nasty problem of secret zero, right? Which is like, great. I moved the passwords into some sort of key service, key management service, but how do

I get the password to access the vault? Right. Where do I store that? Yeah. I put that in a text file and I put that in the same location as my app. Oh, hold on. That's not secure. Well, so you get this like turtles all the way down problem. And really the only way to solve that turtles all the way down problem is you need to have a platform that injects your initial secrets. So we did this very well in Cloud Foundry, right? Like we had this component where when your container launched, the platform created a certificate to identify you. We put that certificate on a temporary in-memory volume. So you could just read the certificate from a file. And that looks like it's part of the file system. I was really sitting in the machine's RAM. And every container got a completely different certificate. And that certificate was rotated every 24 hours. So it was like the cred hub magic that was part of Cloud Foundry, right? And that's a good way to do it because you're injecting the secret into that. And you can see, you see the cloud providers do this too. Like when you launch a virtual machine, they'll give the virtual machine identity. And I'll say, here's a key pair that describes you. And so like learning how to handle secrets is the second big thing that I want developers to know. Right. And I think, I mean, I think cred hub and Cloud Foundry is a good example of, of getting the security people to make it easier, right? Like instead of the developers having to figure out what to do, it's more like, oh, we'll do this for you. Just like, here's the thing that you need, right? I'm going to give it to you. You're not responsible for that. And just use the thing. Like that's all, that's all you don't need. That's, you don't have to worry about that so much, which I think is, I mean, I guess it is an inversion of, of, uh, developers making their applications secure instead you're doing the invert of that, whatever, but yeah, you're, you're, you're, you're, you're not out going out to look for things, but you still have to know as a developer, how do I read the certificate?

How do I check that it's for sure? Like now, now that it's expired, cause it rotates every 24 hours, right? Uh, I need to be able to like switch it. So I need to know how to set up my own custom SSL context in Java, for example, and you go to set that up and you're like, oh no, it's asking me all these questions. I don't know what they are. Stock overflow. What should I pass in for these parameters that I don't know? And then it becomes kind of like, there's still like the APIs are horrible. Generally speaking, most security APIs are terrible, like absolutely terrible. They're easy to misuse. And, uh, what makes it even more scary for developers is when you try to say, what are the best practices for using some security thing? Like say AES, uh, or, or, um, or JSON web token or whatever it is, something that you're, the library you're trying to learn is this. Then you're going to find, if you search for videos, a whole bunch of security people ranting about how terrible the standard is and developers should never use it. Right. And here's everything wrong with it. And your systems are going to get hacked if you use it, blah, blah, blah. But then those same security experts don't offer an alternative or they offer an alternative and it's so opaque. You're like, oh my God, I'm just a peon. I'm just a developer. How am I supposed to evaluate the somewhat well-known security person's opinion on something? So I kind of like, like a good example of that is, is like JSON web token, like the whole Jose standard of it's used by open ID connects. If you want to do a single sign on with, you know, log in with Google, log in with Facebook, whatever people want to do that in their apps. And they, they get stuck when they try to configure that because they don't understand those standards. Right. And because they don't understand those standards, they got stuck. And like, but when they try to learn them, they see a lot of like, never, ever use this because it's a terrible standard. Well, why? And what do you want me to use? I'm not Google. I don't have an alternative to this, but I have to use as a corporate developer what's

available to me. So there's a lot of that fear mongering and not enough knowledge from the point of view of the developer to evaluate, is this safe to do or not? It sounds like a much worse version of, of the whole, I think we've gotten better at this than we were over the past few years, but it's, it's, it's a much worse version of the Kubernetes is too complex reply that you get a lot, which is, which is sort of like, well, well then maybe we should make it not so complex. Like, and, and, and, and also to your point, let's talk about how to like, make it easy to use. And like, you know, instead of just giving up and saying it's too complex, we should figure something out around it. All right. So, so we got the, we got the mutual, mutual TLS and then, and then we got to know about secrets management. What, what's another, what's the next sort of like foundational thing people should know about? The next, the next foundational thing is how do you log people into your applications? Okay. We hate passwords. I hate passwords. I don't like passwords. Passwords are terrible. And ideally your application should never have to store usernames and passwords. So you need some sort of single sign-on solution. So there's really two standards that I want developers to be familiar with. One is open ID connect because it's so widely deployed these days where, which allows you to do like these, you know, log in with the SSO server type functionality. And then the other one is a newer protocol called web authentication. So if you've never tried web authentication, you can go to webauthent.io and there's a simple experience there. What it does is absolutely brilliant. It allows your web app to use whatever biometric system exists in your laptop. So if you go to there with your phone and you go to register, you can actually complete a complete signup flow without ever having to type in a password. And then when you come back, it says, oh, you're on an iPhone. Would you like to use Face ID? And you go, yeah, sure. You log in with Face ID. And it does that whole thing in a, in a secure way.

So if you have like a, like a secure YubiKey, you know, those USB phishing resistant keys, you can plug it in. That works. If you have your, your little thumbprint reader on your Mac, that works. So web authentication is a protocol that I want a lot more developers to know about because it does make things easier for developers. And it does eliminate the need for passwords. Yeah. That sounds great. How, how come everyone doesn't use that? Is it too new? It's new. And there's not enough developers that know how to know about it. Yeah. Is that the, I mean, this is the kind of a, a side concern. So let's say, let's say that comes around. Right. And, you know, now that I'm thinking of it, I'm trying to think if I've actually used, anyways, whatever, like how long does it take like security policy people to say like, all right, we should use this. It's totally okay. I mean, they could, they could say that all they want. If the developers don't know how to write code with it, it doesn't matter. So, so, I mean, I guess that's what I'm getting at. It is for something like that, whenever there's a new, better way of doing security from an end user perspective or a, what's the opposite of an end user, a start user, like, like, is it, is it often the developers who are the bottleneck on it just because they don't know or understand it, or is it the, the policy people or like, what, what do you think? It's really, it's really the architects to a certain extent, right? Because think about it like this, in an application, a typical application, let's say you have 10 developers working on it. Let's be honest about it. One of those developers is going to configure, configure security, right? Right. It's not going to be all 10. And that developer, the developers are kind of being measured on how fast they're implementing the features. And the security feature is going to look like, make the application secure. Okay. The users want to be able to log in. So, there isn't somebody that's actually prioritizing and breaking that down on product management to say, we want web authentication. We want passwordless logins, right? And if they're aware, then it goes to the architects. We're going to say, well, passwordless login, let me scratch my head.

How can you possibly do that, right? And then they need to start searching on things. So, I hope I end up playing a small part in helping people know that the web authentication protocol exists and getting them to try it out. Well, you should write your next book just on that. That would be fun. Because I think the proposition, I mean, the benefit of like, you can make a login system that doesn't require passwords, right? Like, that's a very simple to understand awesome thing, right? And then it's just like, all you got to do is use this technology, which people will tell you that it's complicated and it's hard because it's security. But just read my book. It's actually fine. I'll explain it to you. Yeah, it's kind of funny you mentioned that because I put together the outline for the book I wish I had. It was like 700 pages. And I'm like, oh, it won't take me that long to write 700 pages. Oh, no, it will take me a really long time. So, I kind of got stuck with the outline I went to Manning with. And it's because it's the book I wanted to read. And it really should have been like four separate books. But I don't want people to pay four times for something. So, I'm sucking it up and I'm doing the 500, 600 page book. Oh, wow. Okay. Well, okay. Which I wish I had not done. But I know I'm not doing it because I keep my word on stuff like this. And, you know, so it's I hear you. I hear you on that. Like, it's this is why what I love about Manning 2 is they have the meet program. So, as I write the chapters, they'll become available. And the way I write the chapters is first I write the sample applications. And what I love about Manning is they really want you to have like a real world scenario. So, I come up with a real world scenario that developer would face. I write the sample application that's going to be explaining how that works. And then once I have the sample app, then I need to fill in all the text around the sample app to explain how that app works.

Yeah, yeah. And that, I hope, will make the book good in the sense as a developer, when you encounter something like web authentication, it'll be like, okay, the right thing to do when reading my book would be to clone the Git repo, run the sample application, click around, understand what's happening. We're like, wow. Okay, now I know what it is. Let me actually figure out the details of how to implement it. Yeah, yeah. I mean, I think that's the approach, I mean, having been, formally having been an application developer, right? Like the way that I always want to learn anything is starting with an application, right? Like, you know, bringing up, like bringing up again, like in the Kubernetes world, I'm lazy, so I'm sure this exists. But like, I always want to read, like, I've got this application, now I'm going to deploy it on Kubernetes, right? Rather than learning the bottoms up thing about Kubernetes is a great representation of the atomic units of infrastructure through APIs expressed in YAML. Like, I just want to be like, I want to deploy this app. What do I do now? Yeah, exactly, exactly. And that brings me to the next kind of major thing I want developers to know, which is how to securely deploy stuff on Kubernetes. Because Kubernetes kind of emerged as that kind of higher level abstraction than virtual machines, right? And it is API-based. Yes, it's very complex, but, you know, Tanzu and others are working on making it more accessible to developers. And it doesn't hurt you if you want to advance your career as a developer to understand some of the security aspects of that. So in the book, I'll explain, what do you need to know about how to secure your application running on Kubernetes? Like, it's not going to be a reference manual. It's not going to give you like the how-to tutorial necessarily, but it's going to say, here's what you need to know. Here's why you need to know it. Here's enough about it at a high level. And, hey, maybe you want to go and read some other books to go further deeper into like the nuts and bolts of that, of how that works.

And so, you know, the things so far I want developers to know, one is know how to set up mutual TLS, get really comfortable with TLS, get really comfortable with securely handling secrets, get really comfortable with all the different ways, different ways of logging people in that don't require passwords. Get comfortable with how to package your application securely in a container and run it securely on something like Kubernetes. And then finally, the final problem is the, I would call it the impossible to solve problem, all right? This is the service-to-service authorization because you get things like, say you load up an Amazon webpage, right? And, you know, you might have a microservice that tells you the rating. You might have a microservice that gives you the description of the book. You might have one that tells you what the price is, calculates the discount. So in these modern cloud-native apps, you have a service that calls a service, that calls a service, that calls a service. It could be like a really complex chain, and it becomes not very easy to know like, hey, I'm like 10 services down. Who's actually making that call? Who's the user? How do I know who this person is? And there isn't really a good way to solve that in the industry. There are different approaches that have different pros and cons. And the security people are so freaking opinionated about it. It's scary. It makes you as a developer kind of go like, ah, I just touched the hot stove. Why are they spewing all this stuff at me? Because I put up in an architectural review meeting. I had the, I, you know, I said there's an API gateway here. And like, they're like, how are you pushing the token? And it's like, so I, in that section, all I can do is just explain the different patterns that are available. And the pros and cons of the different patterns. And just arm the developer with enough understanding that at least they know there isn't a better solution out there. Right? For sure. This is kind of the patterns that are available. And pick your poison from these combinations of patterns. Do you want to do a service mesh? Do you want to do API gateways? Do you want to do some combination of the two?

Uh, do you want to roll out something like spiffy, which is pretty damn awesome at solving that problem, but it's, it's not there yet. Uh, widely deployed. So. Yeah, no, I, I like, I like, yeah. I mean, I've, I've only read, uh, so the, the, the draft I have, I think is just like 120 or so pages. So I'm going to look forward to the next, what did you say? 800 pages. Just to add on to that, the multi-volume set, but yeah, I, you know, on, on a topic like this, it is, there, there's a huge advantage to being comprehensive, right? It's, it's, uh, it, it is nice, but, uh, so that'll be fun to read. But so, uh, I mean, if people were interested, is, is there kind of like a, uh, uh, uh, an open review of it or like, what's, what's the, uh, what's the setup for it? So the setup is you just, if you want to read it, just go to manning.com, search for securing cloud applications. And, um, what you'll be able to buy is you buy the early access version. So you can pick to buy the PDF or the PDF and the printed book when the printed book is released. And then, um, as every couple of weeks, you're going to be more chapters showing up. So you start reading it as the book is published and that allows you to, uh, there's also like a, an art, like a forum, which you can access and ask questions about the book. Like, Hey, I tried the sample. It didn't work. Or I'm confused about something. Can you elaborate more on this or that? Which is helpful for me to try to, to make the book better. And, you know, all things, uh, equal, I'm hoping really, really, uh, working hard to hit, uh, summer 2022 target for this. Uh, so hundreds of pages to write. Yeah, no, that sounds good. All right. Well, do you have, do you have a Twitter handle or anything you want to send? It's, uh, a S a I K a L I. So, uh, uh, a Psycali and I'll be posting on there whenever I have new chapters out there. Yeah. Well, great. Well, thanks. That was fun to, uh, it's always fun to talk to an author of something that I've been reading through and, uh, especially on a topic like security. Well, as always, this has been Tansu talk. If you want to get the archives for this show, uh, you know, other episodes, you can go to

tomzutalk.com and, uh, I'll put some links in the show notes to, uh, what we talked about here. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.