How to use DevOps tools with One Identity Safeguard

This is the key point of our DevOps strategy. If you create friction for the developers, they're going to check in a password, right? Because they won't want to use your vault. If it becomes difficult for them to use the tools that they love, then they may not do anything secure at all. So our approach-- posture is, have them use the DevOps tools the way that they need to. And most of these already exist. Azure has Key Vault. Kubernetes has Kubernetes Secrets. AWS has the secret management service, right? Like all of these technologies now have a great vaulting technology involved. So why should we reproduce that and force them into our tool, right? What we would rather do is say, keep using your DevOps team. But when the DevOps world needs to touch the Safeguard World-- the PAM world, we're going to do that in a very specific way, right? We don't necessarily want the DevOps world to reach back into PAM and pull a secret out. That's scary, because now, like my public environment's touching my private PAM environment. Don't do that. That's going to be a bad idea. So instead, we will take the secret from our secure environment and push it to the environment that needs it. Does that make sense? So I'm going to show you a demo of that. And I think that's it. So this is what it looks like. Consider, you have a virtual Safeguard running somewhere. There is a service called the Safeguard DevOps service. It's being written as an open source project. It's currently in POC right now, in sort of an alpha stage. But I have a video of it working. I'll show you in just a minute. It is a service that has a plugin framework-- that it knows how to-- when certain secrets are configured in a certain way, it knows how to pull the secret and push it to the secure-- to the less secure DevOps environment. Does that make sense? We got a plugin already for HashiCorp. We're working on it for Kubernetes. And I'll demo the Azure key vault to your right now, OK? So this is our strategy. The PAM world and the DevOps world are not exactly the same world. But Safeguard is the very best tool for enabling your DevOps world, to get you where you want to be, OK? There is no-- we won't say hey, no. You shouldn't do that. If you say, well, I'm going to just take a Safeguard vault, and I'm going to use the API. And I'm going to use it as my DevOps secret store. Go ahead. We can do it. Its-- Safeguard is flexible enough to do exactly that job. But I would also recommend that you keep that instance of Safeguard separate from your PAM Safeguard, right, and then you push secrets between the two. Does that makes sense? Because you want to maintain that degree of separation between what is considered DevOps and what is considered [INAUDIBLE], OK? Any questions on anything before I start, see we get some demos working? OK, all right. So first thing I just want to show you is a video, OK? I'm going to stop this before we get here. Back up. Back up. Back up. OK, so what you're looking at here is actually a Azure portal. Anyone using Azure a bit? OK, so you're looking at Azure. We're just looking in inside it, at some secrets in the key vault, OK? So this is going to move pretty fast. That's why I stopped it. But what-- I had a developer prep this for me yesterday. And what he's going to show you is that he's looking in at these secrets. And there's just, there's nothing in there, OK? No secrets, OK? So he's going to go back out. And he's going to pull up Safeguard. He's going to take this user that he's configured in a special way. And he's going to hey, I want to change his password, OK? So that password change, you see that happening in Safeguard on the left there, on the left there. And he goes back over to Azure. And he hits refresh. Secret popped in, right? Now it's been distributed out to the Azure environment. And here's its value, right? That secret is now available for any application that needs it through the native tool-- let me make sure we get this across. Stop it. Through the native tool that the developer already wants to use-- Does that make sense? That's a key point. The developer, when he writes the application, he wants to use Azure, Azure key vault. He doesn't want to learn how to pull a secret from Safeguard, necessarily. Does that make sense? OK, so now, you go back in, and you change the password again. See it doing the normal Safeguard thing there on the left. For those of you that own Safeguard, that all looks very familiar. Jump back in. He's going to refresh the view in the Azure portal. When he refreshes it, you'll see, hey, there's a new version of this secret, right? Let's go click on that one and see what its password is. Go down and look at it, and that secret has a different value. Making sense? So who owns this secret? Not as Azure key vault. This secret is owned by Safeguard, managed by Safeguard. It is inside my PAM environment. It is under my control. But where it needs to touch the DevOps world, it's in the tool that's going to make the developer the most comfortable-- the key point to what we're trying to say here. OK, so Safeguard is the tool that provides this type of flexibility to you-- no, no copying and pasting, not moving things manually-- it's-- whenever that secret needs to be changed by compliance requirements in the PAM environment, it changes. So like you can think about-- that could have been a Safeguard instance running in Azure that's managing a VM, that's also in Azure. But when we want to go pull that secret from an application running in Azure Web Apps, right, it pulls it through the vault because it's easier, right? The developer knows how to do it. He's not going to sweat it. So a key factor in using the built-in technologies with something like Azure key vault is because they have certain knowledge about the environment that allows them to anchor a root of trust. For example, if I want to be able to get a pull secret for pulling some print from the Azure key vault, I can base that on the fact that I know which IP I started the VM to run under. Azure knows that this thing can talk to this thing, If you try to do that in another way, it's really difficult. Because you end up like in this scenario where it's like, well, I need a secret to pull a secret. Well, what's going to protect that secret? Well maybe it's a secret, right? Like you can chain secrets together forever. But eventually, you run out, right? Like you have to have a firm foundation to stand on, right? With Safeguard, that's actually the hardware, in some cases, that you stand on, that says, because I know that these disk drives only run on this machine, and that they're fully encrypted, and they can only boot in a certain way, and bootstrap the application, that's my anchor of trust. It's a little bit more difficult to do that in other virtualized environments, right? So in a DevOps world, you can anchor the root of trust in different ways.