Dan Popescu: [00:00:00] The biggest challenge is making sure that secrets do not end up being publicly exposed, but then it also comes to rotating the secrets, making sure that the right people have the right access. Why not use cloud native? To give you a sense of scale, we have involved more than two million secrets. I think four to 500,000 requests a minute, you will end up paying a lot.

There's not a cloud native tool that you can use that facilitates access from bare metal to AWS to GCP.

Ashish Rajan: So I guess you bring it back to the whole conversation that having something like a standardized secret management tool, which works across your bare metal on-prem cloud, everything makes it a lot more easier.

Dan Popescu: And I think this is where to, like HashiCorp Vault acts like a bridge of communication, which makes it easier.

Ashish Rajan: Secret management is a complex topic, especially if you work in an organization which has bare metal, hybrid cloud, public cloud, private cloud, and probably a lot more different kind of complexities.

That are running [00:01:00] in your organization. I had the opportunity to talk to Dan SKU from Booking.com where he spoke about the challenges of deploying a secret management software, which is agnostic and the choices you have to make for why not a cloud native solution versus going for a cloud agnostic solution.

What are some of the trade-offs for doing secrets in on-premise versus cloud and how the connectivity would work and what are some of the good places to start? The conversation was about the. Project that he did across Booking.com for standardizing secret management and this was recorded at HashiDays London in 2025.

If you know someone who's in a fast moving complex environment trying to secret management at scale, I would definitely check this episode out and definitely shares this with anyone you know who's probably solving the same problem as well. Now, if you have been listening or watching a cloud scary podcast episode for some time, and if you haven't, find them valuable.

I would definitely appreciate if you take a second to just hit the follow subscribe button if you are watching this on LinkedIn, on YouTube. But if you're listening to this on Apple, Spotify, definitely give us a subscribe. [00:02:00] Follow there as well. I really appreciate the support and I hope you enjoy this episode with Dan and I'll talk to you soon.

Hello and welcome to another episode of Coffee three podcast today we are Hashi Days London. I'm called Dan. Welcome to Showman. Thank you. Nice to be here. And thank you for the invite. Awesome. Maybe to start off with, if you can tell us a bit about yourself, what you've been up to, and what's your background in tech?

Dan Popescu: Sure. Hi, I'm Dan. I've been working in the past seven to 12 years in large corporations. Mainly dealing with like very large infrastructure across clouds. So I have experience with a AWS bit with GCP Azure. More recently with in Booking.com with bare metal. Oh, yeah. Yeah. And managing Vault.

And yeah. I've been doing work, DevOps, work monitoring automation of the development. Quite a skill, a bit of a few things from each kinda

Ashish Rajan: fair. And today we are talking about the whole secret management thing, which is your topic here at HashiDays as well in terms of secret [00:03:00] management.

What are, maybe if you describe, 'cause a lot of people may think that secret management, just like username, password, right? What's complicated about secret management in a large, complex environment?

Dan Popescu: The biggest challenge is making sure that secrets do not end up being publicly exposed.

But then it also comes to rotating the secrets, making sure that the right people have the right access. So authentication, authorization or policy policies. What can you access different if we talk specifically about Vault. It's making sure that you have different secret engines. I'm a personal believer that you should not have static secrets.

Always go with dynamic whenever possible. Of course. Yeah. In an ideal world, everything would be, would have a short TTL. Yeah. And they are rotated frequently, but in practice things are more complicated than that. But yeah. So when in Booking we try to now push this dynamic [00:04:00] secret everywhere.

Yeah. Like from databases to the cloud to AWS, to GCP, to we have a mixed, like a very large hybrid environment. 'Cause we used, or like Booking has a really large bare metal footprint. Yeah. Now they've extended to the cloud. So we have a multi-cloud, let's say environment. We also have private cloud, so it's a bit of VMs and so it's a bit of a hybrid, large environment.

Yeah. Vault somehow sits right in the middle because there's no kind of direct. Native integration between all these cloud providers and our bare metals. So Vault deals with basically it's a broker for authentication and authorization.

Ashish Rajan: But no, but I guess you, to your point about you've come from a full cloud world as well, the mix cloud world.

Yeah and I've been drinking the AWS koolaid for a long time as well. I was, as I was telling you before, and once I, I think the realization when you start going to [00:05:00] multi-cloud and hybrid cloud, and the secret management. One of the conversations that I've ended up having with a lot of people has been around why not use cloud native?

Like I think, 'cause it's all integrated, it works with all the AWS services from AWS Azure, Google Cloud.

Dan Popescu: So yeah, I hear this a lot as well. So to give you a sense of, it all depends on scale and numbers. Yeah. Because as we know in public cloud, you're paid for storing secrets, for retrieving.

So to give you a sense of scale we have involved more than 2 million secrets. Then these are just static secrets. Yeah. Not like about dynamic secrets for engines, for different databases or such. And then we have, I think four to 500,000 requests a minute. Wow. Okay. Spikes that. So I'll let you calculate how much this would,

Ashish Rajan: so at that scales, you reckon the cloud native ones basically Yes.

Don't perform well.

Dan Popescu: They do. Okay. Probably that you'll end up paying [00:06:00] a lot. It costs a lot more. Yes. It cost. I like there's. We can do caching and stuff, but there's no really, like when it comes to this large number and also making sure that cross cloud providers, you have the same kind of toolings.

Ashish Rajan: Yeah.

Dan Popescu: And the same access. Yeah. There's not a cloud native tool that you can use that has facilitates access from bare metal to AWS, to GCP, to AliCloud, to OpenStack. So it's yeah.

Ashish Rajan: Oh, actually, to your point, and I guess maybe, maybe I'll bring this up again then from a secret management perspective, it's not just username password now, right?

Because in the library cloud, what else? What would be other kind of secrets? 'cause a lot of people would think, I have one password that would that or

Dan Popescu: most of the time you do, but you, there are certificates, so there are access Key? Secret. Secret. Yeah, exactly. There are like all these cloud providers, they have, like for example, there is the Double Secrets engine, which is available in Vault or the GCP Secrets engine.

So there's [00:07:00] granting short lived tokens that apps can use to interact with clouds, right? And there's also vice versa. So you have a cloud provider and you want to access internal. Network. Physical network actually. Okay. There's the other way. There's that or cross clouds. How do you go from an app that lives in AWS to accessing GCP to accessing open stack?

Our internal bare metal infrastructure? You gotta have something in the middle. That Agnostic.

Ashish Rajan: Yeah, agnostic as well.

Dan Popescu: Yeah. So something that allows you to do these operations.

Ashish Rajan: Maybe considering you've done the secret management part across Cloud and BareMetal, what's a good place to start doing secret management?

'cause I think there's a, I guess there's, obviously that's me assuming that no one has done any secret management, which has never grew for any organization. Everyone does some kind of it in terms of. I guess starting to clean it up and become more cloud agnostic or vendor agnostic for lack of a better guess.

I

Dan Popescu: think it also depends on the company, right? When you start small, yeah, [00:08:00] you should always use what's fastest, what's really like the best way to get a product to market. But I kind arrived always in, in large corporations where they have this really huge infrastructure and bridge the communication between them.

So I would say in the beginning, it's probably best to go with if you're just in AWS with AWS secrets manager . Yeah. But then when you start like scaling and some companies just live in cloud. Yeah. So there is no kind of bare metal footprint or other tell that they need to interact to with, so there's no really a way to.

Do things differently. You can in theory deploy an EC2's Vault or whatnot, but I guess it's more comfortable to just use the cloud solution and also be aware of the cost, right?

Ashish Rajan: Yeah. Yeah.

Dan Popescu: Because we have such a large infrastructure, I guess teams do not really care how much, how many secrets do they store because we are. The licensing costs aren't on the number of secrets. Yeah. Yeah. So the orders [00:09:00] order number of requests. Yeah. Which is really critical to to the whole concept of managing secrets. But if you have a few apps or even a large infrastructure, but few secrets, I think it's best to go native

Ashish Rajan: and maybe the next part of it, the whole lifecycle management part as well.

Then for secrets, you mentioned. If you identify a secret has been exposed on the internet. I think we saw the example, which is pretty common, where people use secrets and GitHub and collaborators as well. The lifecycle management of it becomes quite challenging, is what I imagine.

Dan Popescu: Or it depends on the secrets, right?

If it comes to tokens, for example, if you're using a, something that generates a short lived token, you can just refresh it, right? Yeah. For some are, it's difficult to revoke them. Okay. Unless there is a lease or somewhere on identification within the secret engine that does, oh, this secret that has been exposed matches this lease.

Yeah. You can just revoke the lease, which can Vault for certificates, if you have I can talk about Vault, [00:10:00] right? Vault has PKI. Which allows you to rotate certificates. Of course, if your root certificate gets you problem. But you should never keep your root certificate. You should keep it in a, in an actual Vault. Yeah. Fair. And, but if we're talking about intermediate certificates or yeah, app certificates, those can be rotated pretty easily. And yeah, I think the most difficult part is like rotating static secrets in case they are cached in the apps or not, so for example.

It's easy to rotate the secret in the source of truth. Yeah. Like a secrets manager or a Vault. But then if it's not refreshed automatically in the what it's used on the apps, then yeah. That can be challenging.

Ashish Rajan: I love to also ask about the bare metal side of things. What's secret management like in bare metal?

'cause I think some people obviously have a lot of experience in mixed environment, but Yeah, a lot of people to what you said, have always only worked in cloud. What's the challenges with secret management in a bare metal?

Dan Popescu: So as with [00:11:00] clouds, your application will, let's say it runs on a Azure VM or an EC2, or you'll have some sort of identity that can authenticate against the local IAM provider and obtain Yep.

Access, right? With bare metal, you still need the source of truth. You still need to say, okay, this machine is a physical machine with this role, has this access to this specific. Role, let's say, involved and has access to these paths. So first of all, making sure that when you boost up the actual bare metal machine, everything is configured.

That is one thing. Yeah. Which usually is done with pixie boot, like Kickstarter script and things like this. In cloud you would do with cloud in it. Yeah. So that's pretty standardized. And for bare metal specifically because Vault is like it. Actually a lot of applications within the bare metal machine depends that Vault is up and running.

The Vault client, the Vault agent it needs to be just before the [00:12:00]machine is bootstrap, it needs to be configured and ensuring that machine is properly has access before, let's say you come up with a configuration management tool like Ansible or Puppet or Chef whatnot.

Because most of the times, yeah, these will also depend on some sort of secrets to configures, to configure a I own agent for monitoring tool or so on.

Yeah. So you still, you and then the problem because if that machine does not have proper identity, how do you identify if this pixie boot machine with this IP. Should have this role, right? So you need some sort of service directory or inventory management solution to identify that this machine can actually access specific tasks.

Ashish Rajan: But what if Vault was not there? What would be the challenge? I'm current coming more from what you said about cloud, no matter what service you use, you have an integration to, whether it's a secret manager or Vault or whatever.

Yeah. Whereas my understanding of the bare metal space is more like it, it's like each one of it is like a individual box and you, and somehow [00:13:00] draw a thread from each one of them for some kind of commonality. Other challenges like that with the complexity of secrets.

Dan Popescu: Most of the times where if we're talking about bare metal, you would have some sort of layer that manages the machines themselves, right?

Yeah. But if you don't have that layer, you need something on the machine itself to identify the machine, right? Yeah. It could be the IP address, the Mac address, the host name, something that is configured right when the machine starts, and then you can identify the machine that, so for example, i've done in the, what I've done in the past is that I've used to run Puppet master less on the bare metal machine. So it used to take all the Puppet configuration, run it locally. Oh yeah. This configured a bunch of facts. So some static metadata based on the machine IP, host it, and so on. Yeah. And then we could identify that machine as being alive, but usually we, but this is, let's say, is not the most secure way because Yeah.

Things can happen. A lot of times we used to have a certificate management, something that generates a certificate for this [00:14:00] machine and so yeah, you still need the mechanism to,

Ashish Rajan: So I guess you bring it back to the whole conversation that having something like a standardized secret management tool, which works across your bare metal on-prem, cloud, everything. Yeah. Kinda like the standardized approach makes it a lot more easier to Yeah. Automate and scale and do the lifecycle management as well.

Dan Popescu: And what is nice is that, for example, in in Vault specifically, you have all this integration, like AWS authentication.

Yeah. Which specifically ties to the instance profile of EC2 and it goes to the SAPI and verifies your machine or. Signature of the, it's called a C four, I think. So it's, it, you are, it's very easy to integrate authentication with Vault. Yeah. From AWS, but then the same with GCP or other cloud providers.

Ah. So then it's once you have this easy way of authenticating into Vault. Then it is just about Vault, you manage Vault to give access cross, cross cloud access or cross roll [00:15:00] access. Ah, it. And it makes it easier. And for Vault specifically, we use Terraform. Yep. To configure it. So then you have a state, if things go wrong, if somebody drops some policies, you can just rerun it and configure it

Ashish Rajan: and 'cause again, it's an open source version as well.

So it's not that people have to pay money for if they don't want you. They don't have to go.

Dan Popescu: We have the enterprise solution, but yeah. The difference is like you can do. Vault and I've seen actually in a previous company that they used to open source Vault, but they had like individual Vault nodes deployed across multiple regions.

Yeah. And then each Vault node had the same configuration. Yep.

Ashish Rajan: Yeah.

Dan Popescu: So then it's just a matter of conveying the same configuration to all of them.

Ashish Rajan: Yeah.

Dan Popescu: And once you have a layer of making sure that, let's say the authentication goes to the right node. Then Yeah, you can do this.

Ashish Rajan: That's another point that I wanted to call out as well, because you mentioned cost earlier about, hey, it becomes quite costly to use cloud native solutions.

And I think the funny thing in all of this is also the fact that there are open source version that you can start off with to know, Hey, is this the right version for me to Yeah. Working with? And is this the [00:16:00] right step forward? Because another thing that comes to mind is also the whole virtual machine world.

The Kubernetes workload is what I was thing with, because these days most people are going container workloads containerization is still a lot popular than virtual machines. How is secret management different in the container Kubernetes world compared to a regular virtual machine?

Dan Popescu: So most of the times those loads around the Kubernetes cluster needs some sort of secret. They need to authenticate, they need to, so you still need something for that. But when it comes to containers. For example, in Booking we, we wrote our own custom stuff. Okay. Before there was like a secrets operator or I think Vault used to have what is called a Secrets agent injector.

Ashish Rajan: Kubernetes has Secret Manager as well. They have, yeah.

Dan Popescu: Yeah. I've actually used open source version in the past. Yeah. And it worked fairly easily. The only problem was that it's difficult to use that I don't remember what was the name, but was difficult to use. I think it's secrets Manager.

You can find [00:17:00] a journal. Yeah, I think, yeah. Yeah. The problem with that is if you have clusters which are shared across teams, then it's difficult to spare responsibility. Because how it used to work, as far as I remember, used to create a CRD in your name space. It used to fe the secret, but then the problem becomes if that.

Controller runs on the cluster and it has access everywhere. Yes. Itself.

Ashish Rajan: Yes. And I think all your pods have access to it as well. I think. Yeah.

Dan Popescu: So how we built in the past when I used to actually manage kubernetes cluster, we would, because they were fairly cheap in AWS to control plane EKS, we would just sharp bike clusters basically.

Is, this is a group of teams. They own these projects. They have a cluster, yeah. Five machines, 10 machines, haul machines. So then we will have over 100 clusters and then. We really didn't care about.

Ashish Rajan: Oh yeah. 'cause individually each team would have, yeah their secrets in that one cluster that doesn't.

And they

Dan Popescu: had their responsibility of making Ah, yeah. And each cluster had their own secrets operator.

Ashish Rajan: Yeah.

Dan Popescu: But now with the, I know [00:18:00] HashiCorp, and this is one project that we are looking into as well, they offered the, I think it's called Vault operator. Okay. So this is the new thing that actually.

Helps you fetching secrets in the actual name space. But yeah, something along those lines or us at the moment, we have a custom solution that basically runs a sidecar Vault sidecar. Yeah. Which is secrets. There are some issues here because it runs in every pod, which means that if you have a thousand pods it been or a thousand kind of authentication to Vault.

Yeah. The same fetching of the secrets. But it works so far and we are planning to go.

Ashish Rajan: Fair. And would you say, talking about dynamic and Static Secrets as well what's the challenge with moving from static to Dynamic Secrets? In terms from the application side?

Dan Popescu: Yeah. That, that, that's a problem.

So you first need usually what you do is to have some sort of caching layer, either on the app or somewhere close to the app. So in case, let's say the connectivity between the app and the Vault, or like your secrets [00:19:00]manager goes down, you have a local case. So you probably carry the secrets on disk.

Now, if you don't have a refresh mechanism that, let's say watches the file events, the file system events, when the secret is updated or such,

Ashish Rajan: yeah.

Dan Popescu: Then your app wouldn't know if that secret has changed or not. So we would still use the old credentials. Yeah. Because our secrets or our dynamic secrets have.

One hour. Yeah. Usually detail or less, so they change frequently. All the apps have clients they watch when these secrets change and they refresh it from this. So you need to have a refresh mechanism. With static secrets you keep it four years, then you never care. So I think that's the biggest challenge.

'cause you, there are, like, you have apps in Python Pearl Java. Yeah.

Ashish Rajan: Or not you gotta, so you would need to work with the application team to make that like a, it's almost like we need to be a sync between, hey, if we are saying as an organization that, I don't know, half an hour is a time that we are gonna sync our new secrets then.

Every [00:20:00] application that's basically adopting that has to make code changes, whether it's in cache or not in cache that they have that sync that happens with whatever the secret management solution is.

Dan Popescu: Or you can have your own mini API, okay. It leaves locally. Your app only interacts with that no matter the app code.

Oh, you'll do some Mac DP calling and then the demo itself with making sure that the secrets are there and so on. So it is somehow like a middle layer between Vaultage agent and your. Internal apps. Yeah. Because you'll need authentication authorization of the apps, so Yeah. Yeah. You will have, in our case apps that want to use the Vault.

API they call directed agents locally.

Ashish Rajan: So I was also gonna talk about machine users as well. So obviously you're talking about me as she as a user. Maybe I'm doing federation and I get logged in. I use my secret manager wallet or whatever.

But these days it's not just my employee who has secrets, it's my machine users who also have secrets like your IAM roles and other things as well. How does [00:21:00] this dynamic change everything we spoke about in terms of machine users for on-premise, bare metal Yeah. Cloud. How does that change for machine users?

Dan Popescu: For bare metal, you need to have some sort of authorization or like IAM developed solution that gives an identity to the machine. For cloud, we mentioned you pretty much have an IAM role different attached to your and the same for, I would say the same for Kubernetes. If it's non cloud.

Okay. Yeah. For AKS, for example, in, in AWS, I remember we used to use Q2 Yum. Or something was something that you would annotate the pod and it'll get an identity. Yeah. They have pod identity now. Yeah. But on bare metal, yeah. You would still not you would still need something to, right now, I think there is for if you deploy Kubernetes on bare metal there are tools to do that.

So we still need some sort of identity for machines. Yep. So then, okay, this machine is, has this role or whatnot. Again, sometimes this comes down to having some [00:22:00] sort of local metadata on the machine. I've seen this a lot, facts or whatnot, or like a local file that has some. Metadata in it which is provisioned when the, which is written.

When the machine is provisioned. Yep. Yeah, because whatever, let's say you have your data center, you still have some sort of IP mark, whatever you can identify somehow the machine itself.

Ashish Rajan: To your point, as long as you couple that with your machines that are rating more often, that basically you have dynamic secrets, you have dynamic post boxes.

So I IP is dynamic as well. Yeah, you can, I guess all your point, you get to more secure posture as you keep adding more dynamic layers in.

Dan Popescu: For example in Booking we have some custom tools. That when you provision a machine gives you metadata on it. Okay. So basically because we are using Puppet a lot, Puppet needs to know, first of all, does this machine is who it says.

Yeah. Yeah. So what we do is that we use what is called the NC provider in [00:23:00] Puppet. Basically it you use that source as a source of truth. And then Puppet relies on it to making sure that, okay, this machine actually has this role, this whole thing, this IP. So this is how we basically identify the actual bare metal machine.

Ashish Rajan: Ah, okay. And I guess to your point with the machine user part. Yeah. Would that be any different or how would you still treat them as a regular employee user with secrets?

Dan Popescu: Usually not. It should have some sort of token or run out something that identifies it.

Yeah. But yeah, it should have a different kind of, because most of the times for example, in our case, or like from what I've seen in other companies is that machines usually read. That's right. Apps read. Yeah. And then humans write.

Ashish Rajan: Yeah. That's right. Especially, yeah, you're right.

Machines rarely write something.

Dan Popescu: There are occasions, but what we. Because we've saw the, we've opened up some APIs from Vault with internal teams and we saw them like killing Vault because they forgot they had a bug or whatnot. [00:24:00] Ah. But with specific use cases, there was an app that was writing a lot of secret somewhere, doesn't matter, but it was a specific use case for this app.

Yeah. But usually it's like there's a team you need to access, I dunno, GitLab, whatever. You need to access some part of the infrastructure and you'll have a secret for that. If it's static, then you can write it. Yeah. If it's dynamic, then you don't need writing in the first place because it'll be based on a role or something in the backend that like, yeah.

Ashish Rajan: So would you say then to make this, I think maybe 'cause a lot of people may listen to this and go, okay, I probably need to do some kind of standardization for secret management across the board. How do you look for a good starting point to look at secret management as a, hey, this is, these are the kind of projects that are good ones. Or should you start doing that in cloud first and then move to bare metal? What's your recommendation for people starting secret management and that they want to standardize across the board? Static, then dynamic, whatever.

What's a good place to start?

Dan Popescu: So I assume that when you start, you have maybe one environment it leaves somewhere [00:25:00] in a, like either cloud or bare metal or whatnot. So then you should start with whatever is again, available here. Whatever is easiest. Yeah. But let's assume complex one. Like an enterprise one.

Whoa. It depends on what access you need. Do you need bare metal to cloud or both ways you need cloud bare metal,

Ashish Rajan: or would you look at that first or would you look at, hey considering cloud already has some native stuff in there, in terms of quote native there's a lot of APIs that I can use. Are those easier to standardize with the secret manager?

Dan Popescu: Okay. You have bare metal. I wouldn't say so. Oh really? If you have a mixture between bare metal and public cloud. The bare metal needs to access the cloud.

Ashish Rajan: That's right. Yes.

Dan Popescu: So most of the times, let's say you start in the cloud and then you move to bare metal.

Yeah. You still need both communications and they other way around. Yeah. The bare metal and then you migrate to the cloud. You still need them because what happens is like you have an app that lives in bare metal. Yeah. Now that team does not want to write a whole new app. To move to the cloud. Yeah, so usually we would need to have some [00:26:00] network of standardized tools.

So the, for the team, the dev team does not matter for them if they are bare metal or Cloud. Yeah. And I think this is where to like HashiCorp Vault, they acts like a bridge of communication, which makes it easier. Like for example, I've seen teams, large teams that instead of going in AWS. With cross account trust in IAM for example, you're in one project A and you want to access some roles in project B on database or hard disk, they actually go to through Vault instead of going through the native solution because managing trust I am trust account at scale.

Ashish Rajan: Yeah.

Dan Popescu: It's fairly, quite a complex. Yeah. Yeah. Running some sort of Terraform you need to write yeah. All these policies, you need Tori, run it frequently while with Vault, you onboard it to Vault your role. Then the whole configuration is done in Vault.

Ashish Rajan: Okay. Awesome. I think so for people who are walking this journey in terms of understanding was there [00:27:00] any ches as you have done this across the board, was this any learnings that you wanna share with people that, hey, watch out for these kind of things?

Dan Popescu: There are things specific to Vault that I would say, for example, avoid as much as possible role authentication. Okay. Because if you're using a multi-region setup, then the problem be if you try to authenticate against a PR secondary, let's say, then there could be replication delay between the primary and the secondary.

And we have actually encountered this, but of course this happens at scale.

Ashish Rajan: Yeah.

Dan Popescu: So probably if you start small. I would say start small. Yeah. Yeah. This is the first thing. Start small, do some sort of capacity planning, like to understand, okay, where are we planning to be in five, 10 years? Maybe thing like, let's say one two years.

Yeah. And then based on that, come up with some numbers, some, and then I guess price plays a lot of plays a lot of role in that. Yeah. Whatever solution you choose or so on, [00:28:00] it could be cheaper. Should go with the cloud solution. If you have I dunno, small number of things or you say, I don't need the enterprise solution from Yeah, whatever sequence management tool.

'cause there are others by the way. So I've, in the price, I work with others. I would say, and of course, with time you would still have technical debt and stuff. Yep. I think this is unavoidable. Yeah. Some. At some point it was still, oh, we made this decision and then now we got a right. And actually a lot of times, this is what happens in my team, there were some decisions taken in the past, which worked back then, which were okay.

The scale was manageable. Everything worked. But now, five years after we, okay, we gotta redesign this part or rewrite this thing. So yeah, I think it's learn. Across the as time goes and try to iterate, like to well, sounds awesome and adapt how you call it. The technical debt is always yeah.

That doesn't end. That doesn't end. Yeah.

Ashish Rajan: So that's most of the [00:29:00] technical questions I've had of what, three fun questions for you as well. First one being, what do you spend most of your time on when you're not trying to solve the SRE problems of the world?

Dan Popescu: Wow. Interesting.

Actually, I. Develop my own stuff. Uhhuh. My I used to play a lot of games, but now I mostly replace that with mostly write Flatter. Oh, love flutter. Yeah. Yeah. And dart. So I'm writing my own it's still a playground, let's say, but I've evolved into writing this mobile app, which has a go backend and a bunch of kind of databases and search engines and stuff that I'm not able to use at work.

Oh okay. From, yeah, it's like my hobby fair. And besides this spending time with the family. Yeah.

Ashish Rajan: Fair. Yeah. And what maybe that's a good segway to my next question. What is something that you're proud of that is not on your social media?

On my social media. Yeah, that is not on your social media.

Dan Popescu: Oh, this is a very tricky question. Work related or

Ashish Rajan: could be anything, could be work related. My child, but she is also, yeah, [00:30:00] also she's there also. That's a good answer. Yeah. I'm sure yeah. May maybe we'll play this to her as well, so she knows that Yeah, she called her.

Dan Popescu: Yeah. Yeah. Yeah. I yeah. Don't think about this that often. Yeah.

Ashish Rajan: Final question. What's your favorite cuisine or restaurant that you can share with us?

Dan Popescu: Oh, interesting. Me and my wife, we are both foodies. Oh. So what we do, we live in the Netherlands. We travel a lot in Belgium or France, where we go to this kind.

Or even in Netherlands, we go to like Michelin restaurants. Yeah. Go to with the experience with Multicourse and stuff. Yeah. We actually do it fairly frequently, so we are foodies, but I would say favorite food. I like fish a lot. I like to eat a lot. Yeah. I like, yeah. So there's a lot of,

Ashish Rajan: you're true foodie.

You like all of it. Yeah. Yeah. It taste is good. Yeah. Yeah. But if you had to pick one, what's the what's your

Dan Popescu: I dunno if it's a specific cuisine or, I like this kind of multi-course experience. Oh, and we like add tastes a lot of different taste flavors. And flavors. Yeah. Like they're all, it it surprises you, this is a small thing.

Then it tastes oh my God, it's oh, that's a, that's so interesting. You could, [00:31:00] the cuisine itself could be only Michelin star cuisine. Yeah. Yeah. By the way, I've been to like Michelin star restaurants, which were like very, like a small family restaurant. Yeah. In Belgium and nested in a forrest.

It's very, like the whole thing is, oh,

Ashish Rajan: okay. I'll add that to my list as well, but dude, that's most of the questions I had. Where can people find you to talk more about the stuff you're doing and talks as well, I guess LinkedIn. Yeah.

Dan Popescu: I do have Facebook, but this mostly family, I don't,

Ashish Rajan: yeah, fair.

I was gonna, I'll put the LinkedIn one, only LinkedIn and

Dan Popescu: yeah.

Ashish Rajan: Okay.

Dan Popescu: And I have Twitter, but I don't use it. I just follow people. I

Ashish Rajan: think most people don't use Twitter anymore. It just basically goes and just go, okay, whatever's happening in the world, it's going on fire. So that's okay. But dude, thanks much for coming in.

Thank you for so much for inviting me. And yeah, thank you so much . Thanks for you tuning again. We'll see you next time. Peace. Thank you. Thank you so much for listening and watching this episode of Cloud Security Podcast. If you've been enjoying content like this, you can find more episodes like these on www.cloudsecuritypodcast.tv

We are also publishing these episodes on social media as well, so you can definitely find these episodes there. [00:32:00] Oh, by the way, just in case there was interest in learning about AI cybersecurity, we also have a sister podcast called AI Cybersecurity Podcast, which may be of interest as well. I'll leave the links in description for you to check them out, and also for our weekly newsletter where we do in-depth analysis of different topics within cloud security, ranging from identity endpoint.

All the way up to what is the CNAPP or whatever, a new acronym that comes out tomorrow. Thank you so much for supporting, listening and watching. I'll see you next time.

‍