Discovery and Analysis for Hybrid and Multi-Cloud Visibility with Infoblox Universal Asset Insights

Okay. Glenn Sullivan, senior director of products here at Infoblox, gonna talk to you about Universal Asset Insights now, and we're gonna jump right into it. What are the problems that we're, we're looking to solve here from a challenge perspective?

Right? So, asset insights is really a network discovery, right? It's network discovery for on-prem, it's network discovery cloud.

It is the way to reconcile what you've designed from an IPAM and DNS infrastructure standpoint to your as-built environment, right? You know, as network engineers, we have a picture that we like to draw and say, this is the way the network looks. Uh, asset insights is the way to figure out if it's the way that it actually looks.

So we know that managing networks is difficult, right? Especially if you're managing on-prem and cloud, especially in multi-cloud or multi-tenancy. Um, you have limited visibility as a network team for what has been allocated and used by the cloud team.

So depending on how siloed you are, this, this problem can get worse. Um, but in general, even in very integrated teams, we find all the time, the, the use, the primary use case of, Hey, I gave a slash 16 to the AWS team, they started carving it up into slash 20 fours for their VPCs. I have no idea how they're being used.

They come back to me two weeks later, they say, Hey, I've run out of ips. And I say, as a network engineer, I gave you 65,000 IP addresses. What did you do with them?

And they're like, we don't know, because they don't speak ip. They speak applications. So there's this primary disconnect with how networks are planned and managed and how networks are used in the cloud.

We see this back and forth all the time. So there's no centralized visibility for the network team on the allocations they make. And even in the cloud ops teams, there's no centralized place where they're seeing all of the ips across the board and how they're being managed across the different cloud environments.

So what is this? What happens, right? This can cause, uh, overlapping ips, right?

This can cause outages because maybe that VPC that was isolated last week now needs to talk on-prem. So either I've gotta come up with some, you know, fancy nat solution for translating the ips, or I have an eye conflict because I didn't realize that there was an overlap between, you know, on-prem and, uh, the cloud. The other problem is IP exhaustion, right?

So, you know, what can happen frequently is, is I'm either running out or I'm using too many, right? So the cloud team gets, uh, you know, a slash 16 or slash 24, and maybe they, they, uh, the network team needs to reconcile some of those ips or reclaim some of those ips for other parts of the environment, right? So it's, it's not just overlaps, it's also wasting ips that you've been given.

So this, this fragmented deployment causes, you know, lots of concerns and lots of issues with trying to find, you know, what's deployed in the environment. And, uh, there's, there's not a lot of tools out there for seeing things that are visible across the board. So this is what we've done with Universal Asset Insights.

Uh, we've, we've had network discovery in our, in our products for a long time, because we firmly believe that the way to reconcile as-built environment with what's designed is to scan on a regular basis what's in the network and see, you know, how are the IPS being used or, or how, um, you know, how, how are the assets in your environment deployed, right? So we've had an on-prem solution for years, and we've also had a cloud solution that relied on servers. Well, obviously servers are, are an, an allergy to cloud ops teams deploying a server and an appliance, no matter if it's virtual or not, they don't want to do it.

They want you to pull the data that you can pull with APIs. So what we've done is we've said, okay, so anywhere where there has to be something deployed, because I have to speak network protocols, and these are kind of, you know, old school network discovery protocols, but these are the ways that you have to interface with a lot of networking gear. S-N-M-P-C-L-I, uh, you know, ICMP, all of the kind of old school protocols for getting, you know, data added network devices.

We call it interrogating network devices, which sounds terrible, but it's really what you're doing, right? Seeing an access point. Tell me about everything that's attached to you.

So we do that on-prem through NOX, we deploy a server, it runs the discovery protocol and the discovery jobs, it pulls the data in. And the nice thing about the solution that we have now is the consolidation all happens in the cloud. So previous solutions, you would have to deploy a lot of probes and condensers and a lot of things OnPrem to be able to reconcile all of the assets, right?

If I have a laptop that's seen on one access point in one building, and then later on in the day it's seen in another access point in another building somewhere, I have to consolidate that into a single asset. I typically would have to deploy a decent amount of, you know, either virtual or physical hardware or appliances on-prem to do that reconciliation. Now, I have a very, very lightweight probing infrastructure, and all the consolidation happens in the cloud.

The other thing that we take advantage from a cloud to cloud perspective is now, uh, any, all of the cloud, uh, discovery that happens from a AWS Azure and GCP standpoint all happens direct API to API. So there's no need to deploy a server or physical or virtual to do that. The other thing it allows me to do, and we're, we're actually, you can see it, it's in orange.

We're adding this now, uh, is the ability to speak with cloud controllers, right? So the last thing I want to do as a, you know, network engineer is deploy something to talk to a Meraki or talk to a mist, right? I have the cloud services for a reason.

I want to interface with those directly. So we're not gonna deploy, you know, a server OnPrem to speak. SNMP to a Meraki controller.

Doesn't make any sense. We'll talk to the Meraki controller directly via the cloud cloud APIs. The last thing I want to touch on it from an integration standpoint is third party, uh, agent integration, right?

So we, there's a tremendous amount of data in your environments that are inside of CrowdStrike or inside of ServiceNow or other third party, uh, you know, uh, solutions that run agents on top of laptops, right? So what we do is we actually pull the data from those third party environments, and we integrate them and consolidate it into our asset information so that when you're looking at the, the, you know, the laptop here as it's scanned, OnPrem from whatever, you know, uh, network device is talking to, we can enrich the data from, uh, what we're getting from, you know, CrowdStrike and or ServiceNow. Not to mention, because we're anchored in DNS and DHCP, we know a heck of a lot of this asset as it's in the environment because it's doing DNS queries.

We know those queries. We are the ones that gave in an IP address from A-D-H-C-P perspective. So, uh, there's a lot of data that we can pull, especially since we're anchoring in DDI as the primary source of information for all of, for everything to do with this asset.

And then you can see that we're, uh, consolidating all of this into, into a, into a work, uh, workspace here, which Jason will get into and show you a little bit about, but what's providing insights on the data, right? Primary use case is reconciling IPM and DNS, but there's some secondary use cases, uh, pulling insights into your asset inventory as well. I have a question, please.

In terms of what's an asset? Asset, is anything in your environment, um, that you're tracking as a, uh, it, it can have an IP or it can not have an ip, but it's typically a, a workstation like this, an ELB, an NLB, um, an S3 bucket in, you know, an AWS. Uh, so it's anything that you're, uh, tracking at that level in your environment.

So it may have an ip, most of them have ips, but some of them do not. What about the containers running it on, uh, a node? Would, would you consider each of those containers an asset or just the node an asset, or is that kind of up to you to make that?

The node right now is an asset. We are looking at doing Kubernetes level insights to provide even more detail to you, but right now it would be at the node level or at the, at the pod level. Um, applications aren't assets yet.

Uh, users will be assets soon. When you say at the pod level, uh, you're saying that Infoblox can do that now, or That's on horizon? No, Kubernetes insights is on the horizon.

It's on the horizon. So we would see the instances or the VMs that that is running on, but we do not go into the Kubernetes layer yet. Okay, got it.

So if you were to go into the Kubernetes layer, like let's say we were talking about pods, does that mean like, let's say you have a sidecar container running, right? Mm-hmm. The containers both have the same IP address, just different ports.

Mm-hmm. Is, is it theoretical that you'd be able to go in and pull mm-hmm. The information from each of those containers?

Yeah. And, and this is where things get a little tricky, because if I was kind of not intelligent about it, and I said, well, every IP in your environment goes into IAM, then we're gonna run into overlaps because, and what, as I talk to more and more cloud admins, they say, I don't actually care if you track who has what ips inside of the pod. What I actually want to know is the pod running out of ips.

So that's the level of insight. Like maybe we gave the, or maybe it has too many, right? Maybe the default size of that cluster is 20 a slash 24, and it's only got 30 ips, so they're wasting, you know, a couple hundred and maybe they should go in and adjust it to a 27.

Those are the level of insights that most of the, uh, cluster admins that I talk to want. Okay. So, uh, asset insights here, uh, you can, you can see from, uh, from this output, we're gonna get into some details on it a little more.

It's pulling in all of the discovery information. It's providing the insights and recommendations based on, based on the findings that we have, based on the data that we're pulling. It's not just a flat inventory, it's also some insightful information about that inventory.

It's a single place to see, you know, hybrid and multi-cloud environments. And for everything that you see, you can drill in and see all of the assets that fit that classification and all of the data that we're pulling, you know, from that provider, right? So it's important that we show you an insight, let you go into the insight, show you about it, and then show you even more details that are based on the source information, right?

So we're pulling all of the information, uh, that would come from the cloud environment for that. A couple of use cases that I wanted to, uh, talk about from our customers, right? From a customer standpoint perspective on asset insights.

Um, the, the one that I comes up over and over and over again is m and a, right? So we had, in our early access program, we had a major media conglomerate company. They buy companies all the time.

They buy little media companies like on a quarterly basis. And the number one thing is they say is, we don't know what we're getting when we buy a company. And, and sometimes you talk to 'em and they're like, Hey, we, we figure this out when they sign the contract.

And sometimes they figure it out, the network team is the last team to know. And it's like, no, no, this is a done deal. You've got three months to integrate their environment.

And it's like, well, we don't even know what IPS overlap. We don't even know, you know, how many Azure accounts they have. So we provide this visibility to them very early on in the process, and we can show them data in a matter of, you know, in a matter of minutes.

Uh, a couple of couple of use cases real quick. We have a power, uh, company that's using us, a international power company, um, and they have over 7 million assets in the cloud, and they didn't know that they had over 7 million assets in the cloud. So we were able to show them insights based 7 million assets.

I also have an insurance conglomerate who has over 4 million assets in the cloud. Um, and that was definitely a wide-eyed moment for these guys when they started putting in all of the, the different, uh, you know, credentials and, and connected all the, to all the clouds, and they saw they had over 4 million assets. A big surprise.

Uh, so these are the kind of insights that we can provide. And then we obviously can drill into the details about what those assets are, but sometimes just the number itself is surprising with that. This is the easier product to show you rather than talk about.

So I'm gonna hand this over to, to Jason so that he gives, gets you guys up to speed. And we would think, like, it's always like, oh, you've got a class A private. So of course, we all choose the same first one, right?

Everybody has eight Always, right? Everybody Has 10 slash eight. Okay?

So I'm Jason Marketing at Infoblox. And then this next demo, we're gonna look a bit at Asset Insights that Glen was talking about. Uh, so I'm starting off here, back on the, um, the, the IP space or address spaces page, right?

Because kind of the, um, the backbone of asset insights is the discovery engine and actually getting all of these assets and all of this data into, into the system. And we do that through different discovery jobs, right? So we configure discovery jobs for cloud providers for on-prem environments, uh, and for, you know, in the future Kubernetes and other things like Glen was talking about, right?

And then we pull in, um, all of that basic data. So for, for example, we'll just, uh, we'll jump into a, um, an Azure vnet here, right? So this is, this is an Azure vnet, um, not one that I created through our portal, but I, but this was existing in Azure.

I set up that, uh, that asset insights job, and it pulls in this vnet. So we can see it gets, you know, the base vnet container, uh, underneath that we're gonna see, see all the subnets, um, and then we get utilization on, on each one, right? And that's, uh, not the one I meant to go into, uh, inside of any of those individual subnets.

We'll start picking up on any of the anything that that was discovered in it, right? And so this gives us that single plane of glass or that kind of source of truth of IPM of, of knowing what's in our Azure environment. Uh, my environment here, we've got, I've got a private endpoint, I've got a load balancer, I've got a vm.

Um, but you can, you can imagine basically anything with an IP address, anything that's got a network interface in this Azure subnet, I'm gonna see it in here. Even if it's just a network interface, somebody left behind and sits, it's sitting there, it's still using up an IP address. So I need to get that into the system.

So that's, that's kind of the basics. And we could go and look through other ones, and we're gonna see the same for other clouds. But in, instead of doing that, um, what I'd like to look at is kind of some of the, some of the stuff we start to do once we have that data, right?

Um, before I even get into the insights, I just want to show you a couple functions just on our, our IPA page here. I'm gonna turn on what we call flat view. And, and what Flat View does is it pulls it out of those unique IP pulls all our addressing out of those unique IP spaces and lets us work with the data set as a whole, right?

So I have a, a, a ton of networks in my environment. IPV six, IPV four. Um, and, and by, by turning on this flat view, I can actually look at those and, and work with them as a whole.

So, first thing on this page that's, uh, that's really useful is just overlap, right? So a very common thing to find, um, in, in networks is overlap thinking. Um, you know, we talk about cloud environments and we've got cloud teams kind of, kind of running wild and deploying their own stuff.

Network team comes back and it's time to get that under control, get it back into the, you know, into the network. We do a discovery like this, and we may run across overlap. So we provide some easy identification for that, uh, where I can just literally click on that yes, in any of these columns next to my networks, and it's gonna help me identify all of the other, uh, all of the other networks that this is overlapping with.

Now, again, we talked, you know, some about like action versus versus data. This is one of those things where there's not necessarily a one specific action I want to take. So I, I'm getting this data and this insight for the customer to be able to make that choice.

Does, does this overlapping network need to be corrected? Do I need to re IP this, you know, these networks or is this behind that? And so that's perfectly acceptable that I'm reusing this IP space, right?

Uh, but either way, getting it, making it visible and getting an understanding of that is, uh, is a great thing. Then we can do some, uh, some really cool filtering, right? So I really like this IPV four utilization.

Um, and I can just take this neat little slider here, and let's say I landed on 77, so I wanna see all of my networks that are 77% utilized in ips, right? I'm starting to run outta IP space. May need to think about either, um, expanding those networks or moving some devices off of them.

Uh, so a quick, quick apply here, and I'm gonna wind up right with, with all of those networks, I can do the opposite too. If I wanna see, say, my underutilized networks, networks where, um, like Glen was talking about with the Kubernetes, maybe we're, we've started, we're not using the IP space, or in my case, I've just handed it off to my, um, to my cloud guys and they're under, you know, my, my cloud guy's asking me for another slash 16. I said, well, what did you do with that last slash 16?

This is an easy way for me to come in here and see if he's actually utilizing that, right? So I can do that zero to 25%, and here I'm gonna see all those networks that are potentially underutilized and allow me to, to work with those, um, make some decisions based on that. A lot of other, a lot of other filters and stuff we can do here.

But I'm gonna move to, uh, the workspaces that, that Glen mentioned as well. And this is where, um, we go from taking that, that raw data and start, you know, running it through, through our system and providing some of those, uh, those actual insights, uh, on the information, right? Um, so things like, since, since our IAM and our, our asset insights is fully integrated with, uh, the DNS system, I can do things like identify, um, devices that have popped up on my network that don't have valid DNS records, right?

Uh, my network's actually, uh, I got a, I got a problem with that. I got a lot of devices on my network that have an ip, they're in my system, uh, but I don't, I don't know exactly what they are in DNS. Um, we can do things like here just a, you know, analyzing them by type.

Uh, we can look at like idle or orphaned assets, right? Think like, um, elastic IP address that's not attached to anything in AWS, it's just costing me a buck 50 every month and doing nothing, right? So we could see that, um, and get that information in here.

I'm gonna jump though. Yep, go ahead, please. Can You explain the terminology of some of those?

I see zombie Sure. Ghost. Yeah.

Yeah, absolutely. Yep. So, so a a zombie almost scared.

It's supposed to be, it's supposed to be terrifying, but That yes, that's what we call the network team people. There you go. No, no.

Um, so, so zombies overall are basically, um, they're resources that exist in my environment, but they're, they're not managed, not utilized in, in some way, um, not doing what, what we necessarily think they should be doing, right? Um, so, so take for example, we have the category categorizations under there of say, orphan or idle, right? Um, so an idle could be that IP address I talked about.

That's, that we would consider that a, a zombie asset because it's, it's out there, it exists, but it's not, it's not working for us, right? Um, it could also be something like a load balancer in, in Azure, AWS, and we can even go into like idle here. Um, and we would see like load balancers or things like that where we're not seeing any traffic passing through.

So again, like here's a load balancer in Azure. Uh, we're, we're seeing no, you know, no traffic, nothing passing through it. So it's, it's, you know, it's, it's there, it's not doing, it's not working for us, right?

Mm-hmm. Um, and then we get down to, to some of those other, uh, types. So a ghost asset is actually gonna have to do with, um, kind of the next screen.

I'm gonna show you where we go into some, um, some of the other insights on DNS records. Um, and a ghost asset is gonna be an asset we, we actually think should be here, but it's not for whatever reason. And I'll, and I'll, I'll tie that in in just a second.

Um, yeah. So let me actually go right over there. I'll go over to, to our, our network screen here.

Um, so this, this monitor here is talking about those DNS record classifications, right? And we have a few different types. So we have, um, abandoned, and an abandoned is going to mean, um, like A-A-D-N-S record that that was pointed to something that, that used to exist in our inventory.

Um, but, but doesn't anymore, right? So it could be like a public IP address, for example, right? If I look in here, uh, one of the top ones I'll see here is a record for, here we go.

We got a record for, uh, for a public IP address. However, I no longer see this public IP address in my asset inventory. And so we think, okay, this, this is an abandoned record, right?

Somebody else could potentially pick up that, that, um, that public address, use it. Now they've got a record with my system, right? And we start getting into those, uh, those reputational things like we discussed earlier.

Um, the other ones that we have here, uh, let's see, we'll go When you say abandoned, yes. And I, I I think of abandoned meaning that you're pinging it or you're checking it, that it's valid or something like that. It's being utilized Or No, it's, it's more, it's more the tie into assets.

So, so in, in this case, it would be that like that that public IP that we looked at, uh, doesn't exist in my asset inventory. So I don't know whose public IP that is necessarily. What If it's, it's, uh, a vendor or a provider that you're pointing towards that it it Should be, yep.

And there, and it's a possibility. And that's why we're, you know, we are, we are providing this, um, as an insight here, but, but there's not, you know, we have the action is we have Suppression as well. So if you, if you validate that this is valid, you can, you can suppress it and say, oh, this is, this is something that I expect to see.

What about reserved or DR ones that you're, you're placing, whether they're not being utilized at this point in time, they will potentially be used if they do come up or need. Sure. And I think we want to, we'd want to do the same thing, right?

We want to, we'd want to suppress that, that record. Yeah. These are, these are legitimate records.

Are they suppressed for a period of time or completely suppressed and that I should be reevaluating them from periodic? Both. Both options.

Both. Can you like suppress by tagging or some, like some way that we can just basically identify it, say, yeah, these are Dr so let's, not yet, but that's a great idea. Yeah.

One question as well. Do you, do you by chance present this in any way as a graph to the outside? 'cause you actually really have a really good mapping of what the application flow looks like.

But I know It's smile Because, because the, because the answer is not yet, right? And, uh, but, but yeah, that is definitely, um, something, something working on for the future, right? Is some graphical representation of these networks.

'cause you're right, we could really tie together how the, how are these networks connected and the clouds, all that different stuff, right? Yeah, absolutely. Uh, so, so the last record type I will show you here.

And I, I think that's a really good example. And this is, um, this will go back to the answer the ghost asset question as well, right? Dang.

Um, so there's dangling record type. And so, so this is, this is again, some, some type of record that that basically points to nowhere. Um, and what I had here is, is I, I had an S3 bucket, I had it turned on, you know, I had it set up for static website hosting, right?

Uh, so A AWS gives me a nice URL to use for that hosting, but I don't wanna use that URL. So I created a C name in one of my zones, uh, for that, for that that S3 bucket. However, I've since deleted that S3 bucket.

It's served its purpose, it's no longer needed, but forgot to clean up that record, right? And so now I can see that here as that dangling record. So like Glen was saying, this is potentially dangerous because someone, someone else could now go out, create an S3 bucket, reusing this name since I'm no longer using it, and they've now got, uh, you know, got a clean record from my environment pointing into whatever, whatever they may be doing.

Probably not something good if they're trying to, uh, mask themselves as me. Uh, and so I wanna take care of that. And so we would also show this, this bucket as a ghost record in our asset insights, meaning, Hey, this was here before, we still have DNS records for it.

Uh, but this asset is no, is no longer here. And that that's our ghost as Well. Can you apply ops policies in here where you could say, I'm not allowed to create a resource unless it has a minimum of one tag, or like, is there a way to create behaviors of how to ensure that that's going on?

It's a bit of an edge case, but you know, I just find people, I used to do this with us. Like, if I see something with no tag, you have 24 hours, I'm gonna delete this, whatever it is. Yeah.

And there nothing, um, nothing native built in for, you know, for, for like tagging policies. Um, so that would, you know, be something that you'd have to educate and enforce. Um, and of course you can actually, We could pull a view from the, the V and say like, find all nont tagged resources and we could at least see the, the view from the top insides info blocks, right?

Glen just added it to the roadmap, Right? There we go. Good idea.

Now that's, see that points to action, right? And that's a great idea. One more operational challenge.

Well, it may be rare. What do you do around collisions of changes? So if somebody goes into AWS Road 53, it's, somebody goes in my fine, Fred Ned goes into Terraform and, and does some magic, and I go into Infoblox NI Os and I make a change.

So three changes are actively happening to the same resources within the five minute discovery window. What Happens? So there's, so there's, yeah, but, but there's also the ownership on the zone, right?

So yeah, there's also a concept of federation, which we are not gonna get into here. We, there's some, we have some blogs published on that. Um, we had to invent a protocol for creating consistency of ownership across I-A-M-D-N-S kind of has it built into the protocol, but IAM doesn't.

So we had to create something called IAM Federation and we have this thing called realms that basically says in the, here's the realm with all the participants, and then there's different owners of different zones, and the zone owner matters in the context of who writes last. So we have some material out there published on that. Nice.

Great. Thanks.