Name: Protecting Azure DevOps and GitHub data with Rubrik
Uploaded: 2026-02-25T19:16:06.206Z
Duration: 44 min 36 s
Description: Protecting Azure DevOps and GitHub data with Rubrik

Transcript for "Protecting Azure DevOps and GitHub data with Rubrik": Okay. I think we're live. Welcome, everybody. We're gonna give it just a minute or two before we we kick it off, but really excited to have everybody here today. We have an awesome lineup of content and hopefully some q and a for you as well as a GuidedLab experience. Really excited to just dive in here in a few short minutes, but just in a minute or two for folks to come online, and then we'll this off. But if you're just joining us now and you're here to talk Azure DevOps, you are in the right place. Let's see. Welcome. Welcome, everybody. K. Perfect. Awesome. If you're just joining us now, you're in the right place. If you're here to talk all things DevOps and Rubrik, hopefully. Thanks for making the time. Okay. We can probably go ahead and just kick it off knowing people will join probably in the next two to three minutes. Thankfully, they won't miss anything other than me walking through some of the back end and logistic items. But once again, welcome to this Rubric workshop. Excited to have you here. We're gonna discuss all things DevOps from the Rubrik perspective. We have Mike Preston online. I'm gonna hand it off to him in just a minute. Before that though, if this is your first workshop, again, welcome. If you've been to one of these before, you know the drill. Basically, Mike's gonna walk through a deep dive of the content. We're gonna get as technical as we can. But really what sets these sessions apart and what make them valuable for everybody is engagement. So if you can, please engage with us via the q and a. The chat is also open. But if you have questions that you'd like Mike to address throughout the session, at the end of the session, please drop them there. Really, it's how we all learn from each other. You'd be surprised, like, you if have the question, Mike one else has it too. Or if you have a use case or something that even is specific to you, it's always interesting. You can learn so much from each other. Mike learns, and, he has, other things that he could share as well that would come up in the presentation that wouldn't have if you didn't ask your question. So I'll get off my soapbox, but please, if you can engage, do that via the chat or the q and a. We'll be keeping an eye on both, but specifically the q and a feature. If you navigate to the right hand of your screen, you should see it there. We also have a couple documents there that you can keep an eye on. And then later, we'll be dropping the guided lab link in that box as well. So please keep an eye on for that. We have about an hour of content, but I anticipate we might end a little bit before that. This session is being recorded as well, so this is not your only opportunity to learn from this content. But, again, joining live is and having Mike here available to answer your questions is part of this whole experience. So, hopefully, you guys can dial in for as as long as we have you for today. And I guess we'll go and kick it to you, Mike, for the rest of the session. Awesome. Sounds good. Okay. Sounds, good. everybody. So so yeah. Thanks so much for showing up, everybody. I am super excited to talk about, Rubrik and our support for DevOps data. That's gonna include, like, Azure DevOps and GitHub. This is a very recent release for us, so it it's still somewhat new out there in the market. So it's great, that we have so much participation. And like Hannah said, if you have questions, like, just ask them. It doesn't even need to be relevant to if it's not even about DevOps. You wanna learn about you you have a question about our Azure support or maybe our AWS support or something like that. Like, we we could we could take this wherever you wanna go. But, yeah, feel free to just throw them in the q and a there. And as I see them pop up, I will attempt to answer them. If I don't have the answer, I'll definitely make sure I get you, the answer. So like Hannah said, we just kinda went through some housekeeping items, some introductions. This is Rubik and AWS, so I could see right there I got an error on my slide. But, basically, what I'm gonna do is I'm gonna run through some a few different slides around, you know, what we mean when we say DevOps data, how we kinda protect and secure that DevOps data, why why you should protect and secure that DevOps data, and why some of the sort of the solutions that I that I see out there today, are they're definitely useful, but they don't really give you the full picture in terms of of what Rubrik defines as cyber resilience. So I'll walk through some slides with that. I promise I'll try to keep those brief, then we'll get into the technical slides where I'll talk to you about how we actually back up Azure DevOps, how we actually back up GitHub, how we do restores, like, what is actually going on under the hood. And then from there, we'll unleash the labs for you so you guys can click through the UI and and kinda, you know, go at your own pace and kinda see how all this stuff translates into the the Rubik Rubik user interface. So with that, I kinda wanna level set, and I'm sure everyone probably knows about this. But as us in IT right now, you know, it's very easy to deploy new workloads, especially with things like cloud. Right? We have Azure on here. So it's very easy to create an Azure VM. It's very easy to easy to create an Azure SQL database, Azure Kubernetes services, Kubernetes and pods, and and object storage like Azure Blob. Right? And we're seeing this big explosion of, you know, data or organizational data likeness in the cloud. And it's not just one cloud. Right? There's AWS. There's Google. There's also Oracle Cloud Infrastructure as well. And then all of the data that we have sitting, you know, on prem in our data centers, in our hypervisors like VMware, Nutanix, you know, things like that, as well as our SaaS data such as m three sixty five and Google Workspace, which we actually just GA ed actually today, support for Google Workspace. So for your, you know, your Gmail and your Google Drive and everything like that, as well as those big unstructured NAS systems that we have out there. So, like, EMC isolons and stuff like that, they're just serving up tons and tons of data and our identity systems. Right? Because we have to sort of manage and secure and protect those as well. So active directory, Entra ID, stuff like that. But the idea is we have, you know, being in IT as a systems administrator or as a platform engineer or it really doesn't matter where you sit. You're dealing with a lot of different services and a lot of data. And, you know, when you start to try and manage this stuff at scale, it really becomes impossible without building some sort of automations around that. Right? So we develop scripts. We use tool sets like, maybe, like, Ansible playbook for config management, stuff like that, Terraform for, you know, deploying infrastructure, things like that. The point is we're building a ton of automation out there. I mean, I worked in IT as somewhat of a jack of all trades system administrator slash developer slash security guy slash whatever for about twenty years, and automation was the only way I actually got through my day. I would never get anything done without building those automations. And and what they kinda look like is, you know, application updates, security fixes, and really, like, infrastructure management. These were the main sort of core pieces that that we see being built out there. So things like application updates being able to update your applications, change configurations, change settings, stuff like that. Security fixes and patches, you know, these are certainly more important today than they've ever been. And then things like, you know, Terraform plans or open to Tofu plans or Ansible playbooks, all that stuff that we're using to manage our cloud infrastructure and our on prem infrastructure. Right? Everything that we use to deploy that, that all sort of falls into this big bucket of automations that we're storing on DevOps platforms. And the big two, the the two that we're mainly focusing on today are Azure DevOps and GitHub. So that's where a lot of this stuff lives because it gives us access to versioning, to issues. It gives us collaboration tools. It really changes the way that we we build out all of those automations. And then we since use, you know, pipelines and everything from all those DevOps platforms to essentially build and and manage our infrastructure. And it really takes a lot off our plate, like being able to build in all the security sort of scanning into the pipeline, being able to build in the TerraForm plans and applies into the pipeline. Like, we can really start to take a lot of the human element out of the mix here, and a lot of this stuff just gets done for us. And it consistently gets done, the same way. So I do see a question popped up there from Oleg. I will get to that sort of once we get through these initial slides. I promise you I'll come back to that, and, I'll just try and get some more clarification there. But, anyways, what I'm saying here is we have these DevOps platforms. They're critical. We do a great job at protecting and securing data in the middle here. Right? Whether it's in our data center, in the cloud, you know, that's that's the obvious stuff. But down here, like, if you sit and think what would happen if your your DevOps platform actually disappeared one day. So all of a sudden, GitHub's gone or Azure DevOps is gone or certain repos are gone or projects are gone or your entire org's gone. You know, how would that sort of affect your organization? Would you still be able to do all those application updates and, you know, all that infrastructure as code plans? Would you still be able to apply them? Would you still be able to apply all those security fixes? If you are a company that builds software, I mean, would you still be able to make changes to your to your code, to your source code and, you know, update that and release new versions and things like that? The answer is probably, for the most part, no. There's probably ways around it, but it's not gonna be easy. Right? So the idea here is that, you know, over the last few sort of years, we've seen more and more attacks. I'd say ever since around 2020, we've seen this great increase in, like, supply chain attack attacks. Right? So attackers actually going after those DevOps platform platforms and the data within it. So whether that's, you know, being expedited by maybe AI generating tons of different code or, you know, being expedited by attackers just getting smarter in the way they do it. Maybe they change a package name somehow, and that gets pushed into the repo, and all of a sudden, we're pulling down, you know, from NPM or something like that, some kludgy package that is not what we think it is, and all of a sudden, there's a a zero day or some sort of exploit into our environment. The idea is or the the main thing is is DevOps data is definitely under threat. And then we've seen it really, really, really recently. This is one I saw about a month and a half ago, I think, that Wizz discovered, which is which is pretty cool, and I kinda wanted to talk about it. Not necessarily to scare you, but just to to show, like, how widespread this kind of stuff is and how easy things can be exploited. So I don't know if people have heard of this, but Wiz found sort of this vulnerability, I guess, in the way, like, AWS CodeBuild and GitHub sort of, used the user IDs and Regex patterns to sort of define who was trusted so they could execute sort of builds and pipelines. So, basically, the way it did is we know what regex is. Right? We use it to match strings, things like that, find patterns in data. So the way AWS code build was was it looked for it looked at the user ID from GitHub that was triggering that build, and it basically did a substring match. It wasn't anchored, so it wasn't looking for an exact match. So it did a substring match on that user ID to a list of trusted IDs. So if you can imagine say you have a trusted ID of one two three four five, and then all of a sudden, CodeBuild sees something, user ID of two three four five without the one, it would see that as a match. It would say that's a trusted user in a way it would go. So that's exactly how this this attacks kinda worked is automation was used to create a number of GitHub user IDs. Once they found a match on a trusted user, a PR get open, that co build would actually start triggering that pipeline run because it saw that as a trusted user. And, of course, they can then just abuse the build context to sort of grab credentials either to the GitHub org or, you know, see what's in the environment variables and stuff like that to sorta get malicious with that and wreak havoc on the GitHub organization. So this is just one example of how one and I don't even know what that character's called, the little, like, hat that I call the hat, you know, shift number six, I guess it is. One character can really, you know, allow somebody into your environment and allow your secrets to be exposed. So, really, what I'm trying to hammer home in is, like, are you protecting your DevOps data today? And if so, what is your strategy to do that? Because it's super important that you do. Right? Like I said, we do a great job at protecting our core sort of infrastructure and our core data and our core identity now, but there's that third piece that's driving all that stuff, which is quite often the code and the automations that we have up in those repositories. So when I asked this question, you know, to some of our beta customers and some of our customers that we talked to beforehand, I got lots of of answers, but these three usually sort of bundled up. So the first one being native version history. So people would say, you know, we are protected because Git by itself, right, is it's a versioning platform. Right? So anytime we make a change, we can always roll back to that latest version. And, again, super useful. This is why we use Git and GitHub in the first place. But the idea is this leaves a huge cyber resilience gap in in your thinking, and that's just because a backup is not a backup if it lives right alongside the source data, and that's exactly where all those versions live. Right? So when an attacker gets access to your repo, they're obviously gonna purge all of the code, all of the versions, all of the commits, all of the issues, all of the PRs. Right? They're not gonna leave stuff in there that allows you to recover. They're actually gonna target the backups themselves, which leads into this sort of next section, which is manual snapshots. Right? We hear people say, well, I take manual snapshots, whether that's manually or, you know, I create a cron job to do a git clone or something like that and pull that data down locally every day. And while this, again, is useful, it does leave somewhat of a protection gap. Right? Because now you're relying on either timed cron jobs to, to take backups when when you need them, and maybe you make two or three changes during the day, and that's not really captured in your backups. Right? Or you're relying on a human to actually trigger off these manual snapshots. And I can say from experience, if it's something you're supposed to do, as a human and it's not documented and things like that, it's probably going to get forgotten. I've forgotten to take backups many, many times in my career before I've made major changes. And, you know, I've been okay probably about 90% of the time, but that 10% is really what what kinda bites you. And then there's sort of another piece to the manual snapshots is where are you storing them? Are they immutable? Are they gonna be air gapped? Are they gonna be outside of the the sort of reach of those attackers? Can they be changed? Can they be purged alongside with the data? Things like that. And then the last one I get is federated local copies. So we have copies of all this data all over our developers' laptops or all over our system and laptops. You know, if it goes away on GitHub or goes away on Azure DevOps, that's okay. We can just push it push it back up into the repo or into a new repo and with what we have, you know, all federated outside. And, again, this is a viable solution, but I don't know how many of you have dealt dealt with, like, sort of wide scale merge conflicts. I've dealt with just small merge conflicts that take quite a long time and require quite a bit of thinking to do. So there's really a recovery gap there. So if you're trying to rein in all these different copies of of the repo that you have across your all these different, you know, endpoints in your organization, you're trying to merge them all together and figure out who has this branch versus who has that branch, who has this version of the code versus that version of the code, what's the latest version, things like that. It does get somewhat confusing for sure. So there's a huge sort of recovery gap and sort of time gap here. Like, it's gonna take you quite a while to get through all of that, which is why Rubrics spent the time to build sort of a a protection solution around this, to deliver, you know, our enterprise grade sort of data security, data protection, and take that and apply that to your DevOps data as well, whether that's in Azure DevOps or, GitHub. And there's three really main sort of pillars, I guess, underneath our DevOps protection. We can see them there. Cyber resilience, automated protection, and and, obviously, having some sort of unified enterprise grade solution. And I do wanna I'm gonna go through these quickly to kinda, you know, tell you a little bit about some of the features Rubrik can deliver over and above those other three that we just went through, and then we'll get into the technical portions. But number one's gonna be cyber resilience. So we talked about versioning, right, and how that's not good. To be truly cyber resilient, you really need to ensure that your backups are air gapped, and that's exactly what Rubrik's gonna do. We're gonna take those backups. We're gonna take them outside of GitHub, outside of Azure DevOps, and we're gonna store them elsewhere. And when we do store them, they're gonna be immutable. So as they're written, we'll leverage you know, in the case of of AWS, you could back up to Azure or gate or sorry. In the case of GitHub, you can back up to AWS or Azure. And in the case of Azure DevOps, we're just storing them on Azure at the moment. But the idea is we're gonna leverage those native sort of cloud solutions like s three object lock and Azure Worm, like the right ones read many to ensure that those backups are immutable. So once they land on the Rubrik platform, they can't be changed. They can't be deleted. They can't be sort of modified or tinkered with. So your backups will always be there as your last line of defense, which is really the driver behind how Rubrik defines cyber resilience. The second piece is that automated protection of flexible recovery. So as soon as you onboard GitHub or onboard Azure DevOps, we're gonna auto discover all of your projects, all of your repos, all of your organizations, And then we're gonna give you that same policy based data protection engine that we have for all of our other workloads, our SLA domain, basically, where you define the end state. Like, I wanna back up, you know, once every twelve hours. I'll keep that for a day. I'll take it daily, keep it for a month, and so on and so forth. And you just apply that policy to your repos or to your projects or to your organization. So you can go at many different hierarchical levels, and anything below will inherit that and automatically be protected. This goes for anything new. Right? If we apply an SLA domain policy at the top level of, say, a GitHub organization and I create a new repository in that organization, it'll automatically pick that up and it'll automatically be backed up. So there's no sort of data protection as an afterthought. Also recovery. Right? Flexible recovery options, super important. So we're gonna allow you to recover, say, in the case of Azure DevOps, if you wanna recover a repo from one project to another project, that's fine. If you wanna recover a repo from a project within an organization to a project within a completely different organization in a completely different other Azure tenant, absolutely fine. We'll allow you to do that. So you have the options to really recover where you want to, and the same goes across things like GitHub organizations as well. And then finally, the enterprise grade solution. And while this one is the less less sexiest, I guess, to talk about, I think it's perhaps some of the most important because we talked a lot about how we do a great job at protecting our cloud data, our on prem data, our SaaS data, our identity systems. But the automations and things that are driving those, you know, all we really have is things like manual snapshots or point solutions that we can purchase, And that's another product we need to learn, more management, more infrastructure to manage, more things we gotta pay attention to. Whereas, you know, Rubrik can bring our enterprise grade, our experience with doing data protection for all these other things and providing cyber resilience for all these other workloads and lets you apply that to your DevOps data. So there's something to be said about that. Right? Rubrik's a very simple product to use. We've prided ourselves on simplicity. It's been part of our design center from from day zero. There's really something to be said about being able to easily onboard a brand new workload into some application. All of a sudden, you automatically have your backups and, you know, you don't require, you know, weeks of training and and different things like that. There's also RBAC, which is another one. Like, we do realize since we are such a wide solution, like, since we cover off all these different workloads, you know, there's no one size fits all. And especially when it comes to, like, your your GitHub backups or your Azure DevOps backups, these may be entirely different teams separate from your IT team that wanna manage this stuff. So you're able to granularly assign RBAC within Rubrik to maybe you wanna let that developer manage their own backups. Right? So you're able to provide them with the ability to log in to Rubrik to do that if they if they want to, and then that way, they don't see the rest. They don't see the VMware environment. They don't see the backups for, you know, cloud or for anything like that. You can limit them just to GitHub or just to Azure DevOps, even to single repositories within the actual the actual products. So you'll see that within the labs when you run through them as well. And then all those enterprise grade features like quorum authorization and retention lock, which are really just value add. Right? It's something you're probably not gonna get with a point solution if you go out there and buy that, which and and kinda what quorum authorization is is if you think of, like, the way attackers work now, a lot of times, they'll target backup systems as well. They'll try and get rid of the backups. Again, ours are airbag tucked away, immutable. They're not gonna be able to find them. They're completely out of band from from the DevOps platforms themselves. But even if they did find credentials and they were able to log in to Rubrik and they were able to circumvent the mandatory MFA and they did get into the the to Rubrik Security Cloud as some sort of administrator, and then they went to an SLA, and they tried to change that SLA. So you know what? Let's keep our backups for zero days, and then that way, Rubrik will expire them, which is the only authenticated way to actually expire the backup is, you know, come from the Rubrik platform itself. Quorum authorization will protect against that, things like that and retention lock. And what that does is require you to specify two people within your organization, that will need to approve any change that's gonna result in an expired backup. So all of a sudden, attacker's gonna come in, they're gonna change that to zero, and they're gonna be blocked from that. So we've really done a lot of thinking about all these enterprise grade features that we can just, you know, continue to to roll into everything that that we protect and any new workloads that we protect. So it truly is, I guess, you know, here's the tagline, enterprise grade protection for your enterprise critical code. So with that, that's kinda what I had for to kinda level set the everything. I am gonna go through some slides now, some text slides around what we do when we onboard GitHub, what we do when we onboard Azure DevOps, and I'll talk a bit about, you know, how the backup process and how the recovery process actually works. So I'm looking at Oleg's question, though, first. And if anyone else has any questions at all, feel free to throw them in there. Says, does GitHub protection include any validation functionality for org? Oh, I there's a read more. That's why it doesn't make sense to me. Org or repository recoverability. So that's a great question that leads into this tech deep dive because I'm gonna show you sort of what we do. We absolutely do have data integrity built into the solution. I believe it's Git verify and things that we actually run against, the restores before they actually happen to ensure that those repositories are intact and to ensure that, they're actually gonna be recoverable themselves. So thanks for that question. Okay. So onboarding. So I'm gonna go through Azure DevOps and GitHub for onboarding. For the backup and restore, I'm just gonna limit it to just Azure DevOps because the process is essentially the same for GitHub. You know, obviously, API calls and things like that change. But the actual way that it all works is is pretty similar. So we'll start with Azure DevOps for onboarding. So we have, essentially, our customer Azure tenant. That's where our Azure DevOps is gonna live. We have Rubrik Security Cloud. This is what you're gonna log in to to manage everything. This is our SaaS based solution, so there's no hardware here that you have to deploy in in able to get access to Rubrik's Security Cloud. And then we have Rubrik's Azure tenant. So this is an Azure tenant that that we own, and you'll see why we're using that in a second here. So the first thing that's gonna happen is customer's gonna log in to RSC. They're gonna say, hey. I wanna onboard my Azure dev devopsorg. They're gonna enter in that org URL and then provide essentially credentials into Azure. And we're gonna use those credentials to to grab an OAuth token and sort of set that authentication up. So setting that authentication up involves, you know, following Microsoft best practices. So we're gonna go ahead and deploy an enterprise application registration in Rubrik's Azure tenant as well as a service principal into the customer's tenant. So all subsequent authentication is gonna flow sort of through this enterprise application and service principle combo here. So all of a sudden, OAuth token's thrown away, and now we have our authentication set up. So then we're gonna create two permission groups within Azure DevOps. One permission group that gives us backup permissions, so essentially a lot of read permissions, and one permission group that gives us restore permissions. This is gonna be the the write permissions. Now you can choose to only give us backup permissions if you wish. This is what we call, like, a true least privilege, model. So if you want to not have rubric, you know, not give us restore permissions at all, you could choose to do that. Just give us the backup permissions. We'll continue to take backups of your Azure DevOps projects and repos, you know, as normal. And then when you actually go to restore, you can elevate us to those restore permissions and then take them away afterwards as well. So if you want if you're a very secure sort of company here, that will allow you to, you know, sort of just operate sort of at least privilege. Service principal's gonna be part of both those permission groups, and then we're actually gonna deploy Rubrik exo compute as well into that Azure tenant. And what this is is like an AKS sort of instance with some lightweight pods that we're gonna use to to spark up and run things like the the git clones, the git pulls, the git verifies, stuff like that. So that's how we're actually running compute within to to gather that information. Now there's a lot of road map around this. There's a lot of road map around providing a fully hosted solution as well. So, you know, keep your eyes peeled. But for now, this is this is how we're going to to to provide those backups. That's the same way we provide sort of cloud native backups for everybody and things like that. For GitHub, so in terms of GitHub, it's gonna be very, very similar. Right? We're gonna provide the OAuth into GitHub. We're gonna ask for the githuborg URL. We're gonna ask for credentials into that. And since GitHub doesn't have permission groups, it more has applications. We'll leverage those. So, again, we'll create a backup application and a restore application. And, again, if you just wanna create the backup application to start with, you can totally do that and then elevate that restore application, you know, on demand if you want to. We're gonna create object storage within a customer cloud account here. This could be AWS. It could be Azure. That's where we're gonna store those GitHub backups. And then, again, instantiate exocompute within that. So it's gonna be EKS or AKS. That's where we're gonna run all those commands. And, of course, metadata is gonna be written back to RSC. So your data itself all stays within the confines of your control. Only metadata comes back to to Rubrik Security Cloud in this case. So that essentially is onboarding. I'm gonna pause here because I do see a couple of other questions. What is the current state of feature parity between the RSE DevOps workload and the BackRightUp product? That's a that's a great question. It's great that they actually know what BackRightUp is. So a lot of this functionality that we've integrated into Rubrik's Security Cloud has come via an acquisition of a company called BackRightUp. Certainly, BackRightUp at the moment still delivers a few more features, but the road map has these coming in, you know, very, very quickly into Rubrik's Security Cloud. So you're gonna see, like, over the next quarter or two, a lot of this stuff just be right into parity in terms of of what we can provide. And as well as I have, can you back up from an Azure DevOps server on prem and restore into a DevOps services cloud? And the answer to that is no. We don't have any on prem, sort of Azure DevOps server support at the moment. I can't say if that's gonna come or not, but, I could say it's definitely not short term road map, at the moment. But so it's great. Again, keep these questions coming. So let's talk about backup, kinda how all that works. So to kick off, we're gonna send a request to instantiate that exo compute, spark up those pods that we need. If it's the first full backup, we're just gonna run a git bundle. We're gonna pull that down into exocompute, and we're gonna copy that full backup over to, the storage account, mark that as immutable. So now it's, you know, tucked away. It's safe. It's It's immutable. It's air gapped. First full backup, completely done. As we move into, subsequent backups, they're gonna be incrementals. Right? We're not gonna take a full backup every time. That seems crazy. So what we're gonna do for is we're gonna actually pull that full backup back into AKS because once the backup job's done, you know, this little bundle here is gonna be purged away. We don't save this stuff. Like, there's nothing persistent about AKS and the and the temporary storage that we have on it. So we're gonna pull that full backup across. We're gonna run a git pull against the repo, and actually create that incremental backup capturing the changes between the latest full and and what's currently present in that repository, and, of course, copy that over to the storage account, mark it as immutable, and then clean up after ourselves. So pretty sort of high level simple process here. Obviously, there's more that goes on, technically under the hood, but I think this is a a good depth to actually, go into. Recovery, pretty similar, and almost, you know, completely, the the opposite of that. So instead, we're going to again, we're gonna ex instantiate, execute. We're gonna copy those full backups as well as however many incrementals we need in order to get to that desired point in time. So however many incrementals we need to get to that desired point in time that that you've selected to restore. We're gonna go ahead, and we're gonna reconstruct that, on the temporary cloud storage layer within AKS, reconstructs sort of that repository, and here's where some of that data integrity stuff comes in. We're gonna run a git verify against this this repo to ensure we have data integrity to ensure that's gonna be able to be recovered. And, of course, it gets copied back up to the repository, and the all the temporary and nonpersistent data in AKS gets purged and and deleted. One thing to note, this repository that we're recovering to is always going to be a brand new repository. That might change. It's hard to say. We did get lots of feedback during beta around we don't want to restore back into an original repository. We don't wanna affect any sort of actions or activity that might actually still be occurring there. We don't want pipeline builds to, you know, kick off when we do the restore and things like that, which could be damaging to the infrastructure. So it's always going back into a new repository. And one part we didn't say here is you can choose yes or no whether you want to restore those pipelines along with it. Right? So you can disable the pipeline, during that restore to make sure that that, you know, doesn't kick off and things like that. So this is what I had, in terms of technical. And, again, if there's any questions about that, feel free to throw them in there. You still got me for another few minutes here, because there is some things I wanna show you. And before we actually get into the labs, one thing I did wanna show was, and and we really didn't talk about this much, but Rubrik is an API first platform. And I think that's super important, especially with this audience in terms of DevOps and and platform engineers and and people like that because that matters. Right? You guys live in automations and the APIs and everything every day. So every single thing you do in the labs coming up here can actually be accomplished through an underlying API call as well. And we have a lot of SDKs and integrations, like Terraform integrations, things like that, everything, you know, built around these APIs that we supply to our customers. And we have a lot of customers that build a lot of cool stuff around Rubrik itself. And this is something I was thinking about just last week. I was thinking, you know, wouldn't it be great if we could just have, like, a GitHub action or something that would run, like, in the pipeline and just take a backup, you know, when we merge to the main the main branch? That just kinda made sense to me. Right? We do a lot of security scanning. We do linting. We do all of this stuff in the pipeline, but backup always seems to be, you know, outside of that and out of band from that. And I don't really know why that is, but I thought, wouldn't it be nice to bring backup in there? So what I did was just create a a simple little, like, scripted GitHub action here just to kinda showcase the value of the APIs. And it all it really does is take, you know, the current repo and an SLA domain within Rubrik, and, you know, it's just Python to trigger an on demand backup, basically. So that's all it does. And then when you sort of attach that to a repo I'll go to this one here. You know, we just simply call it you know what? On any push to the main branch here, what I'm gonna do is I'm gonna run this Rubrik on demand backup action. I'm gonna pass it, obviously, our service account info so we can get into so we can log in to Rubrik. I'm gonna pass it the current repository name, and I'm gonna pass it in SLA domain. And there's an option here to say, hey. Do you wanna block this merge until that backup actually completes? So you could set that to true or false. And then, you know, as just get made to that main, we can see that backup actually take place right within the pipeline. So this is a way where we don't even need to configure sort of a scheduled backup with Rubrik. Instead, you know, you can add it right into your pipeline and say, you know what? Sit around and wait until this job returns successfully, and then it goes ahead and and completes the merge. So just something I wanted to quickly show, especially this audience about how you can integrate with Rubrik, how you can build your own sort of solutions around Rubrik using our APIs and automation. And if you go to developer.rubrik.com, we definitely have a lot of different code examples and a lot of documentation around our APIs. It's something we've prided ourselves on, you know, ever since I joined seven years ago is being an API first architecture because that kind of stuff does it it does matter. Like I said, when I spent twenty years in IT, you know, when we evaluated solutions, if they didn't have an API, and a lot of them didn't, especially fifteen years ago, you know, I'd almost just, you know, qualify them out. Because if I can't automate around it, what's what's the point? Like, I don't wanna manually manage all of this stuff. So for the actual labs, Hannah's gonna give you guys the links to the labs. There's gonna be a couple of them. We're gonna have Azure DevOps, and we also have GitHub. Pretty much, you know, pretty much the same, but you can go through them both, because it is a little bit different. There's different chapters if you need to jump around. So if you wanna look to see how you can, you know, securely use RBAC or if you wanna go through that onboarding process, you can easily jump into there as well as how SLA domains work, how to recover, things like that. Actually, running through the lab, you know, you it's going to prompt you to click on different spots. You could totally just click on that, or you can use your arrow keys if you want as well. So there are ways to navigate just using arrow keys to kinda see how everything works. One question we always get is how long will these labs be available? And that's sort of like I believe it's a couple of weeks afterwards, so it's not, like, super urgent, but I would definitely get them done as soon as possible if if you can. So with that, I'm gonna pass everything back to Hannah. I think I have another. slide of resources, and go from there. Mike. That was amazing. Hopefully, everybody learned a little something there, more than a little. I do have a question for you, Mike. I know we have two links. We have GitHub and Azure. Could you grab the Azure DevOps one and send it to me so I can put it in the chat? It looks like I only have both I only have GitHub, and I'm sure there's, folks who. Sure. with the Azure path. So I'll put that in there. So just hang tight if you guys are wanting that link. I'll drop it as soon as Mike shares it with me. Do you want me to put it there? I can yeah. All good. can I just right at that. perfect. Even better. Let me pin that message. Okay. Perfect. Hopefully, everybody can see that. So if you're interested in taking that route instead or wanted to do both, click on it now. Okay. In terms of, like, where we go from here, hopefully, this was a good little like, it is kind of a teaser. Obviously, I think it's, you know, good to to walk through the technical deep dive, but there's nothing probably more valuable than having, like, that one to one session where it's actually, you know, relevant to your company, what you guys are experiencing with your architecture, and your scope of requirements. And that can really only be done in more of, like, a one on one demo technical deep dive session with an engineer. So I would encourage you to request a demo if you haven't already and meet with the team that is, you know, dedicated to your account. If you're already a customer, I would encourage to bring this up to them, and they'll be able to, you know, educate you further on how to learn more, how to get your hands on the product from there. Because, again, I think this is a great, you know, starting point, but there's so much more that comes after this. So, also, Mike very generously put his email there. So if there's specific questions, about, this session or anything, feel free to reach out to Mike as well or myself. There will be a follow-up email that has some of these resources And, again, like some of those next steps that you guys can take, that'll come in about twenty four hours. This session was recorded, and that will be included as well. But, yeah, be on the lookout for other sessions like this that we have in the future. I know we have a couple coming up in the next few months, so we'd love for you guys to attend those. If there's other topics of interest, we don't just do it on DevOps or on cloud. We kind of all of Rubrik's products are pretty much we're doing these kinds of sessions for. So I'll go ahead and wrap it up there unless there's any last questions. I think that you got to all of them, but I appreciate everyone's engagement. And again, don't stop here. Hopefully, there's more you can learn. I'm gonna go ahead also, I should mention this before, launch this survey. So if you're still with us, it takes, like, a minute to quickly launch the survey or to answer the survey. Just helps us make sure that the content is relevant and that we're doing things that are resonating with the team. So if you enjoyed it today, please let us know. If you didn't, let us know as well. And, Yep. yeah, and we'll go from there. But, Mike, any other closing remarks, or are we good to wrap up? No. I think that's that's great. Everyone should feel super excited because the GitHub stuff actually isn't released yet. So you guys are you guys are actually getting, like, a sneak peek at everything. I think it's coming out in the next, I guess, like, March 5 or something like that. So Wow. Special. yeah. Yeah. Well, everyone, this session is very important, and you guys should fill that because that's exciting. Okay. Awesome. Well, everybody enjoy the rest of your week. Reach out to us with questions, and really appreciate your time and attention. Have a great day.