Ashish Rajan: [00:00:00] Welcome to cloud security podcast today, our guest is Michael. He is a developer advocate working for AWS at the moment, and I’m really excited to have him here to talk about computer security, like Michael, 


Michael Hausenblas: thanks for 


Ashish Rajan: having me. For people who joined know you and haven’t read any of your blogs or YouTube videos that you have, how do you tell people what do you do? 


And. Little people. 


Michael Hausenblas: So on a practitioner trying to help people to you know, use containers safely, you know, the point, these things that you’re running with, those that you heard yourself, for series a product developer advocate in the AWS container server. And container security is one of the main things I’m looking after. 


I’m acquainted his head up and doing cool news for five years. So, obviously very close to my heart, but also observability issues or, or. Tooling challenges around that, maybe CNCF sort source projects, including Flint bid process 


Ashish Rajan: Cuban. And he was definitely how I came across your name as well. 


So we’re definitely on the right topic. I did want to ask, where does it staff developer adequate mean? Like what do you 


Michael Hausenblas: do. Right. Right. So we work together with our customers it’s [00:01:00] inbound, right? To, to understand their challenges, influence our roadmap help RPMs to launch product features and the, the outbound elements in terms of speaking at events or whatever, but it is really mainly working with customers, understanding their trenches or how they want to want to use the product. 


Good PM and engineering into to help launch products. 


Ashish Rajan: Yep. Perfect. And our audience on cloud security, Porter’s very varied. There’s going to be security architects. I’ve got people who are security enthusiasts as well as it’s kind of like a wide spectrum of experience levels. So people who don’t know what CNCF. 


You mentioned CNC earlier, but I know what it is. People may not know what it is. What is 


Michael Hausenblas: that? The cloud native compute foundation has been around for a couple of years. It was initially set up and designed to find a place for. So initially Google owned or, or, you know, created communities and, tried to find a place to, to, make sure that it has a neutral, you know, in terms of IP. 


And then it has a neutral place and the Linux foundation. Based foundation always makes sense when the creditors [00:02:00] CNCF, which now grew, or, you know, we have many, many projects there. When I say we, I mean, with my CNCF ambassador count invested head on. So I feel part of that community. So there are many, many more projects, some of the. 


That directly came out of the communities you know, ecosystem NTD, for example, promos, et cetera, doctors that were submitted to the CNCF and which are now considered a part of. 


Ashish Rajan: That’s a great explanation. I was going to ask you, cause you mentioned cloud and container. And one of the questions that I asked a lot of guests is what does cloud security mean for them? 


But I think what is container security is more appropriate over here in a cloud context or where to spend data security in cloud look like. So there, 


Michael Hausenblas: there are two approaches to that. I believe on the one hand, you know, you can have, you know, come up with you very, very new and exciting concepts, you know, shift left or shift. 


Right. And never remember. So moving more. Self self service for developers. And then many, many other things. If you break it down, really, like I assume that everyone is kind of familiar with what the cloud is, right. It’s kind of like, you know, you rent capacity and we rent electricity, right. Just switched on and pay for whatever you you’re [00:03:00] using this idea. 


And on the other hand containers, as you know, containers, This is our lie, right? I mean, don’t tell anyone, but containers don’t really exist, right? If you look into the Linux kernel, right. Or if you ask Leno’s, if you meet him over a beer, there are no containers, right? There are things like C groups and namespaces, computerized file systems that exist as components. 


And then Docker came along, Docker incorporated. And, and created a very nice thing packaged, you know, the way, how things are run, how namespaces and see groups and whatnot. A little finicky and a little hard to, to use on their own. How anyone, any developer, anyone who is not necessarily even through Colonel can actually use it. 


And that’s what the runtime, the image format, which essentially technically again, it’s just a zip file with the chase. Let the data file explaining how these layers relate to each other. And that’s what we nowadays know and use as competitor. Right? If you break it down, if you have, you know, if a assist admin who has 10 years of Linux administration experience under your belt and you have for using any, any, any cloud, guess what you’re already, you know, very well set up [00:04:00] for container security in the cloud, because you have all these basics. 


Already sorted out, you know, what a namespace does, you know, but a secret, you know, how to look for certain things in, in C groups or namespaces, especially if you’ve been doing stuff with system D you should be rather familiar with the secret place here. So there’s really not much new in terms of. 


Technology’s been around for many years, really? Just about the overall packaging. And of course they’re in you like names, new labels, new concepts. But if you look at any of the given things in quantities, right, what is, you know a service it’s really just a mini load balancer in front of pots for east west. 


Right. And then it’s like many, many of the things that, you know, now have a exciting new name. It has been around and then has been established way, way, way earlier. Now they’ve been kind of like standardized have been formalized. 


Ashish Rajan: Oh, right. And, and to a point, the security of that is doesn’t really change it just more, I guess new services that, sorry, orange. 


So this has been new label, but security context has made it very similar. 


Michael Hausenblas: Right? I mean, if you, if you want, I don’t know if that’s the best. Made it up. [00:05:00] So, you know, if it doesn’t fly and you will see that in a second way where I’m saying I’m smirking at that, they mentioned, you know, you, you look at a plane that was built a hundred, hundred 20 years ago, right? 


Yeah. Basically the same elements is today, right? Wings, engine, whatever. But without any doubt, currently what you’re currently looking at it’s way, way, way more complicated, right? Because there are many, many more things that are automated. We have many, many more moving parts. And so you have many, many more potential points where it could be. 


Right. I mean, it’s still like, you know, at a plane without, you know, with a missing wing was back then the problem. And it’s still a problem, but now you have many, many more problems that we back then didn’t have, because it was like, you know, this, this kind of like mechanical connection between your steering wheel and the back. 


And there was no free computers in there in, in between. So, you know, that kind of stuff. And in the same way, We still facing the same issues, right? You you’re still, if you’re on the blue team and trying to defend a community’s cluster, right. You still have to defend 360, right. It just needs one single [00:06:00] thing to get in. 


Right. This is still the same problem. And if you leave something open, then this is the same issue as having something open on a, on a whatever app server on, on a. Your data center on premises. It’s its richest many, many more moving parts. Things have become many, many folded and complicated. So you need to know, need to be aware of many, many more things that you need to take care of defense and not. 


Like I once said in an interview that I think, and I’ve got a lot of flack for that. I think that communities is actually safe by default. And what I actually should have said is there all these controls in there, not all defaults unnecessarily configured in a way that it’s not an automatic foot gun. So it’s everything is there is. 


You know, disable the things right. Or enabled to things. Right. So out of the box, default is maybe not the correct thing, but all the, it has all the things that, that you need. You know, you have service accounts there, et cetera, et cetera, you have everything. 


Ashish Rajan: Oh, perfect. Yeah, that’s true. I mean, I guess it’s up to the user to configure order, I guess, misconfigured it. 


The other question that [00:07:00] I wanted to ask about was your blog article about polygraph. Cloud native compute. So for what does that, and what can you tell us about that? 


Michael Hausenblas: Right. So the, the, the meme itself is polyglot, blah, blah, is is obviously, you know, a rip off of the, I can’t remember 20. I can’t remember maybe 10, 12 years ago, polyglot persistence, right? 


There’s inside that in context of microservices that you have many different kinds of data stores and, you know, use the best of breed and the best for your use case rather than fitting everything into relation database. And my observation was essentially the same with You know, I see very often discussions, both, you know, in social media and with customers, this kind of like, you know, containers versus Lambda, right. 


Or, or whatever. Right. I was like, well, in reality, I think what we will see over time, and maybe we’re already seeing for bits of it is that we are living in a polyglot world where, for certain things, certain obstruction, they will levels make more or less. So I do not think that there will be a world where, you know, like everything will run in a container and communities, right. 


Or [00:08:00] everything will be Lambda or everything will be mainframes or everything will be VMs. We just have more and more layers or more. Tools in our toolbox made of it. Right? So initially it was essentially just mainframes and then came data centers. And then, you know, you have this kind of virtual machine ideas and then came containers and function as a service lender stuff. 


So you have more and more tools at your disposal to do compute. And then you, your job is essentially to figure out what is the right computer. Unit four given task and the same way that in the context of, you know storage or, or persistence, you would say, Hey, for this use case, I think it’s better to use, a no-sequel pipe database that does key value stores or document view or whatever. 


And here a relation database is actually the better choice, right. And the same way. I think we will going forward. Do that much, much more with that kind of stuff and club leader stuff, as well as a, well, in this case, we need very tight control over everything. So we ended up in a container set up. And in this case, the developer [00:09:00] velocity and simplicity is, is of paramount importance. 


So we are going to go with some sanctions. 


Ashish Rajan: Oh, sweet. The way I analyze this is more like the right solution or tool for the right problem audience in cloud security port. Cause I was saying earlier has a bit of a varied skillset. So if someone who starting today with containers, the Cuban cities in a, I dunno, insert cloud provider here, it could be Amazon Google or whatever. 


What are the basic security things to look out for? Or they could be doing in Tampa sanitation. 


Michael Hausenblas: The interestingly enough, the basic things are really simple, right? You don’t need to, you know, many people see things like. Container image signing and supply chain. And so, and I’m a big fan of it. All I’m saying is let’s get the basics, right. 


Let’s do our homework. Let’s get that, that we have a proper foundation. Then we can build on that foundation to do more advanced stuff, which is cool and interesting, but get the basics. Right. And that includes things like, you know, always defined a user in a Docker file. Right. Because that’s something that unfortunately. 


Well, everything else did it really well. That’s the one thing that the doctor, [00:10:00] unfortunately didn’t do. And that was, essentially not creating this, this pattern that people would copy and paste and use by default the user, which means without the user, the Docker file, it was, might exist at the container image and buying vacation days, container running. 


That is route, which is unnecessary for almost all cases. Then you will, you want to do, which is table stakes nowadays. You want to do a container aesthetic container image scanning. So essentially in the process of, or when you push it into your registry, as I said, it’s table stakes, right? We offer this for free part of VCR. 


So it’s like, I didn’t, everyone has it. Like this is table stakes, but it’s just, you should do it. There’s no reason not to do it. And then from then on it’s, it’s, you know, a number of things that are good practices. But it’s getting already like a little bit more involved in the sense of that. You need to have a strategy, for example, around a container runtime, security. 


How do we go about that? Do you actively look at the run time? What is going on there? Are you using Secombe or whatever profiles that communities have to set that? Right. I using things like pod security policies one of [00:11:00] the low-hanging fruits though, is a network. Which I wish to some extent that it’s, so it is part of is native creditors because you know, the, the, resources exist at the enforcement of these policies. 


You need to do through something, right? You need to have a CNI plugin that actually supports that. And that’s something, especially for networking folks and also security folks, which is probably a bit surprising. By default, all the parts can talk to each other throughout all and see each other throughout all the namespaces right there. 


When I saw that the first time I was like, wow, that’s that’s interesting. So in other words, you pretty much need a network policy that initially just denies everything. Just open up selectively and say, okay, here you can park for this other one and you can have Ingrid, et cetera, et cetera. From a security perspective, Shocking or interesting. 


But as I said again, the things that are there right now, never policies are there. There is no reason not to use it. The requirement is you need a CNI plugging that actually allows you to enforce these network policies. That’s pretty much it, everything else is like, you know, on top of that. Sure. There things, around how to, you know, good practices, how do you deal [00:12:00] with You know, end to end encryption MTLS within typically within a service mesh, you can, go down where you do out of full supply chain management to detract the entire lineage. 


Where does something come from? Including image signing, et cetera. But most, most of the things are already like 80% is already done if you do the basics, right? Yeah. 


Ashish Rajan: I guess to your point are there things like, oh, it’s starting. I need a local registry instead of economics and industry, so that you have a local copy of it. 


Our, 


Michael Hausenblas: yeah, I see it quite often that, you know companies have something, you know, either locally on premises or whatever and, and only essentially push. Maybe once a day or whatever, can proper trusted images to let’s say ECR where they have their product in Wyoming and then yes. It’s for multiple reasons, but yes, one of them. 


Sure. 


Ashish Rajan: Right. Do you find that containers are, femoral to a large extent or is it more long-standing beds also in our beds rather than capital, I guess. 


Michael Hausenblas: Yes. Yes. Yes. So in general it goes even a step further nowadays. I mean, the, the, you know, kids versus pedal cats versus settling [00:13:00] versus, that, that has been around for long and. 


Infrastructure, et cetera. But nowadays it’s actually like treat, treat clusters like entire clusters as, as kettle, right? You should be able to ramp up the entire cluster from whatever your, your environment is. Including all the components that we want to have in there, you know, monitoring, logging, praising, everything, just like that. 


Because if you have an issue, whatever. No, you kid and started fresh, right? Don’t don’t try to fix a cluster and then have the same thing that you had with yams or whatever 10 years ago. And continuous, obviously by extension. And I think the, maybe the more interesting question is if I may slightly rephrase that, is, are they supposed to be stateless or not? 


And that is where it’s a bit like, you know, where do you draw the line? If you look at the level of function, the function. Which by nature by this time is stateless and you have this, It’s challenge of, of what we call state hydration. If you have a function that is stateless and that doesn’t need any state to do something useful, that’s great, right? 


In the same way, if you have a long run, long running container that, you know, just, you know, I don’t transform something, whatever it doesn’t need [00:14:00] any state to function, that’s fine. If you however, need some state, right? You might need to create a relation database or pull something from it’s free or whatever. 


Yeah, external stuff, then what can happen? And that is more permitted with landed, to be honest, but because containers are long running, running all the time, so they can kind of like cash something. The amortization over time is, is, is higher and better, compared to, to short running things like Lambda. 


But still do the, the challenges there. Right? Where, where do you draw the line between the state list? A bit of depends a bit on some experience versus fully state stateful. I have a strong opinion on the most letter, like the fully that the actual like data stores, right. Should I be running a Postgres delay or whatever cluster on communities? 


Like. Sure possible right. There are, you know, you can write a custom controller and you can do a lot of things yourself, but in this case, I would actually encourage people to have a look at what your cloud provider has, you know, in terms of managed databases, data stores, and you probably would be better off with [00:15:00] that. 


Ashish Rajan: So I was always to say, so containers should be stakeless. Is that what you’re saying? And we’ll move data skills to say something like an RBS or a dedicated data store. 


Michael Hausenblas: If, if, if the question is, you know, really a pure data store, right. Database data store, Cassandra and Mongo, D B and post-grads and my sequel, Marie, Maria, whatever. 


My answer would be, yes. If, if you, if you know how to run that thing, right? It’s not only the stories, it’s like many, many, anything that, you know, persistently keeps some data around. It’s pretty good. If you know how to run that thing in a non containerized setup right then great, because then you can relatively straight forward take that experience and. 


Right. A custom controller that essentially codifies what you did manually. And those are many things that it’s like. And I have seen the same thing at atmosphere when we like then wrote framework, scapularis, which essentially is the equivalent to the primitive custom controller. Which did the same thing, right? 


If you knew how to do Cassandra and Kafka, whatever non-continuous set up, you’re able to put them into. Controller or whatever [00:16:00] that essentially does the same steps that you do manually. It’s still hard. I would argue that, you know, if you’re a human and you’ve been operating, let’s say Kafka cluster for, for five years, you kind of like, you know, you just listening to the, to how the lock locks or whatever you can tell what’s going on. 


In coating that into customer patrol is super hard. Right? You can, in general you can say, yeah, you know, if this, the broker is not balanced and create another broker or whatever, but sometimes it’s just the human intuition, whether that says like, no, let’s wait another five minutes that might, you know, with all these exceptions. 


Right. Are you really able to capture all of that? So that’s. Maybe, maybe have a look at what your child provider offers. Maybe you’re better off. I see a lot of use cases where, you know, you have these. You know, we spoke essentially written where we might not even have the, the binary anymore or the SRD source code anymore. 


You only have to buy it then, you know, what can you do other than putting it into, into container Docker file and then creating, containerizing it and running it. And then you might have, you know, an embedded database or whatever, some hard dependency, and you cannot change it. You know, lift [00:17:00] and shift is fine until you are at the point where you can really be architecture, maybe somehow externalized. 


Ashish Rajan: And I think it’s an interesting point because the more complicated you make your structure, the more complicated say something like incident response and forensic could be as well, because I imagine the way I see it, I’m keen to know your opinion on this incident response in forensic doesn’t really change much in terms of how you would do. 


For a container environment in cloud versus a regular server environment or a VM environment in cloud. Is that right? 


Different of course. But 


Michael Hausenblas: yeah, I get that because of the. Usually when you have a, it doesn’t matter if it’s a VM or doesn’t matter, but in terms of the mesh, it doesn’t matter so much. If you have a VM or like bare metal where you typically have to expectations that have months, if not years of running that thing versus containers where you know how you might have a pad of, I don’t know, An hour or maybe less, depending on their workload. 


Right. And sorry, pat said 80% are younger or die after in the hall. And, and this is [00:18:00] kind of like, you know, You can’t really worry about, or, or kind of like focus on this and individual container part, right. You might have for forensics reasons right away. You say you take this part out of the deployment by removing the label, and then you keep it running to do some forensics on top of it. 


Yes. I don’t want to get paged about a random pod in a creative cluster with thousands nodes or Python nodes that has thousands and thousands of pots of running. I don’t even care about an NPD plan. What I care about, what does the overall class to do? How well is it distributed? I might have certain business critical, you know, services or deployments. 


Really caring about, but you know, you, you, you cannot, you might be able to, you know, really scrape all the metrics from all of that for, for other purposes, but you cannot be alerted. That’s just, that’s crazy. 


Ashish Rajan: Yeah. And I think to your point, the thing that created it is the real. I guess the point of interest, right? 


Because container is just creating what it has been unnecessarily, an application, which was somehow had one honorability [00:19:00] and that container was specifically effected resource. Everything has, should have come from template. I could block a file or something. 


Michael Hausenblas: Right. And so that is also, that is an attack vector. 


I’ve seen it already once or twice that sometimes people come with expectations that turn out not to be true. Right. For example, a lot of people believe. If you look at the container image, like Docker, you know, OCI, the image itself, that this is immutable, right? Yep. Which is actually expects. Right. 


Okay. With this tag, you know, it must be the same now turns out that, really like repeatable build that. If you put together a Docker file today, you say, you know, Docker build, I take your Docker file tomorrow and say dot. Then the hashes of our tool container, which is the result, the container, which is, should be the same, right? 


That’s the idea of repeatable built. That’s fine. That’s the idea or the idol case, which is almost never the case because, because, because, because the, the texts in darker, the semantics there is up there that they are. Right. So I might, you know, say, oh yeah, but you know, I’ve been using whatever Emerson didn’t X, blah, blah, [00:20:00] blah, blah. 


And you said, yeah, I used the same. But someone, you know, fix the, you know, some security issue, whatever, and did not decide to create a new tag, but labeled with the same tag. So when I do that build today, I’m actually pulling a different base. Not that someone now kids will do it, but you know, you know what I mean? 


The basic idea. And so the only chance you really have is to, to use hashes, you know, unique, you know, a good commit hash or whatever, uniquely generated automatically applied hashes and not rely on these humanly assigned label labels that you come up with. You know, this is version one point 12 or whatever, because. 


Mutable. And by that, you know, you, you, you never know about a human deciding. Oh no, that’s actually the same version. Yeah, that’s fine. So you really got to be careful, even if you think all of that is totally mutable. Since you do not control, like you control certain bits, but you control a lot of those things, you know, based on witches or whatever out there, are not under your control. 


And you can, unless you cash everything and have everything under your control, which is again, pretty hard to achieve you. You simply don’t have the [00:21:00] guarantee there. That’s where. Coming to this expectation versus reality. 


Ashish Rajan: And kind of going back to that earlier question that I asked you about some of those starting off who maybe aren’t as mature. 


So what’s the mature container security like then. So they were going by the previous answer you gave, would they be having unique hashes for each Kitab commit that has been done, which is used to trace what change was done to a container. So if there was an incident, they can come back to the hash, find out what had happened. 


Michael Hausenblas: I would even argue that it’s not even, like, that’s not advanced, it’s like our, at least in our customer base, like mature customers. That’s good practice. Advance would be things like, you know, someone actually has. You know, for example, an ultra based TuffBase, image, container image signing in place have, some supply chain management like CNCF in total or whatever in place. 


So at any point in time can can say, you know, I’m looking at this container in this namespace, this. I can tell, well, it was this developer at this point in time, and that can not only tell, but can prove that it came from, you know, the desk [00:22:00] off in the same way that think about it. If you, if you nowadays eats meat or whatever you can, or you should be able to frack it down and see, yes, it was from this farmer and, you know, one day on the south end or whatever executive, that kind of thing, right. 


This need that they could end up. That would be a supply chain minute. But at any point in time, you can. Say, and also based on this knowledge, I make policies that you say, well, you know, the policy is, if someone leaves us, then no new images can be deployed. Even if, if it’s still in the registry or whatever. 


Right? Any of these decisions you can only make, if you have clear lineage of, of all the artifacts. 


Ashish Rajan: Right. So how do you see a mature audiences or mature customers measure? Is there a way to measure card security, I guess, or ongoingly? And if so, how often should they be doing it or if there’s a tool for it? 


I guess. So 


Michael Hausenblas: measuring in the sense of like, you know, having a, a, or a set of indicators, I think doesn’t make a lot of sense. I think security is something, it’s like, you know, in, in USIG or whatever, if you stop practicing. Then, you know, you usually [00:23:00] get worse over time. It’s, it’s like swimming up river. 


Which means you can, you can constantly test someone, right? You can have pentesters or whatever, saying like, look we believe that we did all, we covered all our bases. You know, with a certain, tried to get the data, try to do something. And based on that, you can, you can iterate. I, I don’t really think that there is something like, you know, the checklist of things that, you know, I can give a rubber stamp of approval. 


You are, you’re perfect. You set up, this is not, not my, also of my aim. My aim is about awareness because there are so many moving parts, communicating and establishing and community. Good practices around that essentially seeing what, what works father is trying to codify that or share that. And then, and then based on that, as I said, I very much believe in this kind of like, you know, red team pen, tester approach, where you see, where you can actually test your, your, the, the match shields that you put around your infrastructure. 


Ashish Rajan: It would, I mean, cause budget constraints obviously. And a lot of people would just say underplaying, this feature, it’s not really a major feature, just a minor feature. So we don’t really do pen tests like in [00:24:00] how things like that happen. And that’s kind of where a lot of security folks would ask about, well, it’s all well and good. 


But if I were to go six months after a pen test, how do I know what my current security posture for? My kind of cluster is like, things like that. That’s kind of where I’m coming from. 


Michael Hausenblas: Yeah, I think it’s still early days to, to really have a good, solid opinion that, so I, as I said, I believe we all should be doing that and have, have these reviews and then actual. 


It could be internal, could be external. Maybe one can automate, I started moving around and I got a tool that essentially, I don’t know if you’re familiar with this, this idea of doing chaos testing, essentially nuking random. Exactly right. And the question is, can you automate that to some degree, essentially think of it, like, you know, you have something that you, all the known misconfigurations and whatnot that CUNY’s clusters have. 


Points points this script or this tool at your prince cluster and to go, right. And obviously this is not comparable with an actual human doing penetration testing, but you know, kaching, [00:25:00] kaching common things. At least it’s automated. We can run that. I dunno, every other week or whatever, and you get this basic coverage for free, that that would be, and there are already few of those out there. 


I’m definitely not the first control plane, UK based startup Martin, has, has already something out there. So there are many, you know, folks who think along the same thing, at least automating the basics that, you know, people can then focus on. 


Ashish Rajan: Cool. Thank you. Great answer. That’s a good way for me to get into my next segment. The next segment is score muster and it’s basically what are the myths around container security in cloud that you hear quite commonly 


Michael Hausenblas: with campaigners it’s it’s. I don’t know if there are really myths. It’s more like misconceptions. 


Maybe it’s a bit like. You know, expectations being so high that it’s kind of like the silver bullet that solves all your problems where it’s really just like, you know, it’s like, what do containers really do? Well, they do. They, they manage in a very nice way to do application dependency management. Right? 


Yeah. They’re not primarily for isolation guarantees, et cetera. Right. And[00:26:00] that’s where, you know, for the longest time, initially, I remember when we started off explaining containers where we said, it’s not the VM, we meant it always in the, in the deregulatory bad ways. Like, you know, Hey, you know, containers are super fast startup. 


And I remember. I was back at the map bar and we had to look at, I think it was missiles. And we, one of our engineers to a security engineer said, shaking his hands, like, oh, it’s all of them. All of these containers are all sharing the same kernel. It’s insane. 


Right? Yes, there are projects like we have firecracker that allow you to do, to reintroduce this kind of activation guarantees that you had. And without, you know, going back to this like minutes startup time for it yet, right. You still have seconds or sub seconds. But really this, this is the kind of like awareness and education that, that is still very much needed. 


Maybe like bloated expectations, where in relatives, like. It’s just, you know, stuff that we’ve been doing for a long, long time, which now increasingly gets marketed and packaged more sexy terms and more 


Ashish Rajan: so I guess just not the same way. And then what are people not [00:27:00] talking enough about in container security? 


So 


Michael Hausenblas: people I’m. Across, you know, cloud providers and whatnot customers and so on. I think talk actually about the right things. I think that the number one challenge is, and it’s getting better is that it’s clear. It must be clear that in this containerized setup, in any like, Set up where you have smaller units, many of those interacting, if you’re dealing with distributed systems, this, it must be a shared responsibility. 


It must be, you know, this can’t be the job of the security team that comes in at some point in time and says, you can’t do that. You can’t do that. You can’t do that. It, you know, the developers need to be aware of that. Oh, I can’t bake a secret into a computer. I cannot put the passport in there. Right. 


Everyone else who gets considered Manchester possible to, obviously operations, like everyone, everyone needs to be aware of it each and everyone needs to do their share. And, and maybe the security. More from a enforcer and no, you’re not allowed to, to coachee like, Hey, you know, these are good practices [00:28:00] here. 


The tools, how you can check yourself if you conform to everything more like coaches and coaches, essentially. 


Ashish Rajan: No, thank you. That’s a great answer. I’ve got my final section now, which is the fun question. And the fun question section. This was non-technical. So the slide, my first question is where do you spend most time on when you’re not working on say containers or tech? 


Michael Hausenblas: So the answer is it’s, it’s a little sad because my. Like hobby. It’s the same as my top. And that is essentially developing stuff. It could be hardware, software, whatever, but it’s also developing. So our kits for kids 12, 15, and 16, and it’s like, dad, it’s really hard to tell if you’re working or if you’re having fun, like for yourself, because it looks the same, right. 


You’re sitting in front of a laptop, but yeah, that’s true. I’m very sorry. No, but we haven’t. 


Ashish Rajan: And that’s a good way to get into the next one. Then what is something that you’re proud of? What is not on your socials? 


Michael Hausenblas: I’m depending on who you ask, my, my Mrs. Might disagree, but fairly good cook. I, I believe that I’m a fairly decent. 


Some of the kids say yes, some of them say no. Anyway, [00:29:00] I like to cook. Oh, 


Ashish Rajan: okay. That’s perfect for my next question as well, because my next question was going to be what’s your favorite cuisine or restaurant that you can share? Can I, can 


Michael Hausenblas: I say that. The gating I live in Ireland, so I I’m sorry, everyone who watches it in Ireland, anything but the Irish kitchen, like, I I’m really like I’m super flexible anywhere, anything. 


I don’t mind what, unfortunately we don’t have a lot of variety around here in Ireland, so pretty much 


Ashish Rajan: anything, but maybe, let me just say what the thing you enjoy 


Michael Hausenblas: cooking. I do a lot of things. So any kind of you know, vegetables, you know, it could be a combination with cheese or whatever, but I like doing stuff with vegetables 


Ashish Rajan: on them. 


Cool. That, that was pretty much the show, but thank you for the great interview. Where can people find you on social media? 


Michael Hausenblas: Right. So if you take the first letter of my first name and then my last name info, pretty much everywhere else, Twitter, LinkedIn, GitHub. 


Ashish Rajan: It was really amazing to have you. So I really appreciate the time. 


Thank you so much for coming on the show. Thanks for 


Michael Hausenblas: having me.

‍