Frictionless DevOps Secrets Management in Safeguard

Hi and welcome to my session today. My name is Dan Peterson. I am a lead architect of the Safeguard Project at One Identity. And today, we're going to talk about Safeguard and how it can securely help you to move at the speed of DevOps. Now, I've been giving presentations on DevOps for a couple of years at Unite. And I have noticed that every person who I speak to has a different idea in mind of what DevOps actually means. Usually, that's influenced by what projects they are currently working on and how they're being built and delivered. I think the easiest definition that works for everybody is that DevOps is everything that happens from the moment that a developer puts their hands on the keyboard all the way through to the end of the line while the operations team is supporting and maintaining that application as it sits in front of customers. And in fact, you may think DevOps is a continuous cycle. That we're constantly coding, building, testing, releasing, deploying, operating, monitoring, and planning our software in a continuous loop. Where the software that's actually in front of customers today is informing the backlog for what we're going to build tomorrow. The thing that makes it possible for us to get our features in front of our customers as quickly as possible is automation. When a developer writes a line of code and they check it into a code repository, a trigger fires that makes it so that the code is built automatically. As it's built, it's automatically deployed and tested, checked for quality assurance, and then, releasing that software can be as simple as clicking a button. The thing that makes this possible is the automation. We try to keep human beings out of the picture so that things are repeatable. That they happen in the same way every time. And we remove the human error from the equation. And also, we're able to get feedback continually to our developers of code that needs to change and things that need to be fixed. But with these DevOps trends and all these new technologies and processes, there's a lot of new things that need to be secured so that they can be called by automated processes. We need to secure our source code repositories. We need to secure our build systems and our package and image repositories. We need to make sure that as we're deploying to infrastructure based on configuration that we have in our code that it's doing so securely. Now, our applications don't look like the typical three tier architecture of old. But they're complicated systems of multiple microservices all that need to securely communicate with one another. And also, we need to make sure that as our customer data is out near the public cloud-- is in the public that it is protected and that only authorized access is given to the data. Now, the thing that makes this possible, the way that we protect all of these new systems is through the use of secrets. Only those systems who have the correct secret have the ability to access any of the DevOps technologies and processes that I've just described. Now, one thing that's happening is that development is changing so very rapidly. The way that we develop software even five years ago is very different than today. Over the last 10 years, there have been a plethora of technologies that have been developed that it's very difficult to keep up with. I prepared this slide a couple of years ago with all of these technologies that a simple search of the internet looking for DevOps could provide to you. And I have, probably, only used 50% to 60% of these things that are on the slide. And it's probably in those-- since it's two years old, it's probably missing 20 new products that were launched in the last two years. With all of these technologies coming out, it can be a very frightening situation for those that are responsible for IT, for security, and for Ops administration. It can be frightening to them of how can we keep up with all of these trends? How can we keep moving as fast as possible but still remain secure? One thing that can be said is that developers always love using the newest and best technologies. They can't help themselves from pulling the next thing off the shelf. They love to talk about it with their friends and other developers that they're using the most up to date and the coolest stack for their application. And sometimes, this puts them at odds with the team that's responsible for operations and security. They need to make sure that those operations are still secure. And they worry about developers going rogue and operating their own shadow IT just so that they can use the newest technology. So sometimes, the operations department finds themselves in the position of the department of no, where they're constantly having to tell developers, no you can't use that because we don't think we can secure it. Instead, we would like to talk to you about how Safeguard can be used to allow developers to use their favorite tools. So in order to avoid this friction that happens from developers always wanting to use the newest technologies and the operations team from always having to say no, we want to use a new technology from Safeguard called the Secrets Broker for DevOps. This is going to allow the developers to bring their own tools and to use them and the technologies that they feel comfortable with so that they don't try to go around the outside and operate their own shadow IT. So the goal of Safeguard is that it tries to secure your critical infrastructure without changing the way you work. You want your developers to work the way that they feel comfortable so that they'll choose to use the security that you offer rather than trying to go around it. You want them to be able to increase their productivity by being able to use the newest technologies that are made available to increase their efficiency and in their DevOps environment. So Safeguard has built with the next generation architecture. It is built to integrate with any of your systems that are running on-prem, including your DevOps and other solutions. And it's built with an API first design. An API first design means that everything in the UI that you can do in the product is also possible to do via the API. You can automate anything that Safeguard can do. It's built for integration. It has DevOps specific APIs that are built for to be called by an automated process rather than a human. Safeguard also provides open source projects and SDKs so that you can integrate with any technology that you find in your enterprise. And we also like to make sure that our admins who are or managing your secure infrastructure can do so by bringing their own tools. Safeguard has a purpose built application to application API, A2A API, which is really our Safeguard DevOps API. It enables you to use a single round trip to retrieve a credential or to retrieve a secret for use by an automated process. When you think of a pan solution, generally, the way that it works is a human being makes an access request that's approved by another human being. And then, after the secret is done being used, it's checked back into the system. That process is simply not fast enough to work in a DevOps environment. And so the A2A API makes it possible for you to retrieve the credential in a single pass. It's also more secure. The most secure way for one automated process to talk to another automated process is using a certificate and a private key. Also be-- there can be IP restrictions placed upon the calling application so that the server will refuse-- the Safeguard appliance will refuse to release the secret to any caller who is not coming from that restricted IP. There's also the ability to obfuscate the names of the accounts that are being used and to use in their place obfuscated API keys. This enables you to check in your source code without disclosing the names of the privileged accounts that you need to use. Another important capability of the DevOps API, the A2A API, is its ability to monitor a credential in real time for changes. This means that when you are building your application, you don't need to continuously pull the secret every time it needs to be used. Instead, you can cash the secret locally, and only when it changes. And Safeguard changes the password you need to request it. And you can do so with-- in real time. Now, the Safeguard A2A API isn't only good for DevOps, but it's also good for integrating with RPA and other on-prem applications. In order to find the DevOps resources available for Safeguard, you're going to want to go to the One Identity GitHub page. There, you will find SDKs for SPP that are in .NET, Java, PowerShell, and Bash. And also a plug in framework for use with a Safeguard for privileged sessions. There's also an SPP API tutorial. So you can learn how to call the API for yourself and integrate any of the product functionality you need to automate for-- in Safeguard. But most importantly, I'd like to announce that there is a new product available and open source solution called Secrets Broker for DevOps. The Secret Broker for DevOps is meant to be your solution to enable your developers to use the tools that they want to use. And the demos that I present today are going to show you how that's possible. We wanted, as we were deploying our open source solutions, to make them as available as possible to your developers. And we do this by using the native package repositories that your developers are already familiar with using. For example, if you want to use PowerShell, you can pull the module for the PowerShell SDK directly from the PowerShell gallery. The same thing is also true for .NET and using NuGet.org. We're using Maven Central for our Java repository. As you're also deploying these solutions, we wanted to make sure that if you wanted to deploy them in an orchestrated environment that there was a Docker container available with all the functionality that you needed in order to begin interacting with Safeguard. The Safeguard Secrets Broker for DevOps is available as a container and as an image. And that's how I'm going to demo it today. One point that I'd like to make very clear is that when you're interacting with your DevOps in your production environment, it is more secure for you to push a secret out to that public environment than it is for you to pull. Many solutions in the market have your production application reaching back into your vault to pull a secret to use. And this means that you have to make your vault accessible to the public network. We have found at One Identity that there is a more secure way to do that. Like instead, pushing only the secrets that are needed in the public environment to the vaults that need to use them there for DevOps and other use cases. And one way to do this is using the Secrets Broker for DevOps, and that's what will be a part of our demos. So let me describe the demos before I start showing you how they work. There on the left, you'll see that we have a Safeguard appliance that's protecting a secret that's needed for your Jenkins build environment. As you can see, we have deployed the Secrets Broker for DevOps there in a container. And it has been installed with a Jenkins plug in that knows how to push the secret directly to the Jenkins credentials plug in so that it can be used by your build process using the tools that your build engineers already know how to use. They're familiar with Jenkins. But it might be more difficult for them to pull a secret directly from Safeguard. And in this way, you enable your developers to do the right thing, to not hard code a secret, but to pull it from a safe location using a credential store without requiring them to change the tool set that they're using. So the Secrets Broker, as you can see there, it will monitor that password. And I'll actually show you that as it changes, it's updated in near real time in the Jenkins credential plug in. And in the next demonstration, I'm going to show you something that's more like a DevOps style orchestration where we'll deploy the Secrets Broker for DevOps to a cloud environment in a container. And you will be able to use the HashiCorp plug in to populate the HashiCorp vault where your developers are already very familiar as they're building their orchestrated solution. They know how to pull secrets from the HashiCorp vault. Whereas, they might not be as familiar with how to pull a secret from Safeguard. But let's show you these things in action. In this demo, I actually decided to use the MSI installer rather than the Docker container. The MSI is available for download from GitHub. It can be found on the releases page under assets along with all the plug in. So this demo is, actually, recorded from a Safeguard session that I'm doing into a Windows desktop running up an Azure. I'm going to install the Secrets Broker from the MSI here on this machine. My SPP and SPS appliances are also running up in Azure. And Safeguard is granting me secure access into that Azure environment. The Secrets program MSI installer takes a few moments. And when you're finished, I will have a secret broker running as a Windows service on this VM. I'll show you a sneak peak preview of the Secrets Broker web UI that will be released later this year by navigating to local host on port 443. Have to ignore this TLS error here because it comes up the first time with a self-signed certificate. To get started, I need to associate my Secrets Broker with my SPP. Secrets broker can be paired with SPP by logging in as an SPP administrator. Secrets Broker will then trust SPP for authentication and identity. Secure communications between Secrets Broker and SPP uses client certificate authentication. I can use a CSR to enroll the client certificate which would be the most secure way. Or I can just upload a PFX or PKCS12 file. This client certificate needs to be from a PKI trusted by SPP. So let me just find the certificate file that I'm going to use in this demo. And we'll upload that. But first, I need to type in a password to decrypt the PKCS12 file. Now, let's give Secrets Broker a minute to process that and use it to establish communications with SPP. OK, there we go. Now, Secrets Broker uses plug ins to synchronize secrets to other credential management tools. In this demo, we are going to upload a Jenkins plug in assuming a scenario where we have a group of developers who are already heavily invested in a build pipeline in Jenkins. But they need access to a PAM secret for a Siebel database that's actively managed by Safeguard. So once this Jenkins plug in is installed, we need to edit its configuration. Each Secrets Broker plug in can have a plug in configuration details specific to communicating with that credential store. Here, we we're going to configure the location of the Jenkins build server. And we will just need to type that in there. And once we get that specified, we will also need to specify a Jenkins login username. And in this case, it's just user. Because we don't want to hard code a password in our plug in configuration. Each plug in can also specify a vault count, which is an account in SPP whose password is used to securely communicate with the other credential case-- or the other credential store. In this case, Jenkins. So we will just specify which password we want to synchronize over to Jenkins selecting our Siebel account. There it is. And then, we will save off our configuration and close it out. And so, now, our Secrets Broker is all set up to start pushing our Siebel secret over to Jenkins. But before it will start synchronizing, we need to tell Secrets Broker to start monitoring for credential changes in Safeguard. Now, we're going to flip over to the Jenkins' side of this demo to show the Secrets Broker in action. Let me just log in to Jenkins. Need to type in a username and password here. Get that logged in. OK, so I've created a special build job here that is going to echo out our Siebel password. This is, of course, for demo purposes only. But the point of this demonstration is to show that your developers can use the native tooling of Jenkins that they are already know and love to access this PAM secret that is actively being rotated by Safeguard. So here, they have the normal credentialed bindings config that is pulling from the Jenkins' credential store. And down below, we have a script that will display the username and password on separate lines just echoed out to the build console. This said command here is just injecting a space between each character of the username and password. So the Jenkins doesn't try to mask them out of the console log. So let's just take a look at the latest build out so you can see what the Siebel password value was the last time this job was run. So there's the user name. And there is the password with the spaces in between. Now, let me just grab my Safeguard management UI here and let's rotate this Siebel password to watch it update. Just let me scroll down until I can find my Siebel admin account. And we will go to our account security and tell Safeguard to change the password. Oops. My platform task UI is over here on the other monitor. Let me grab that and bring it over and it's already done. So let's jump back into Jenkins and start at build 11. And there we go. Build now. And we will go to that build output when it's done. And we can see the console output. And you can see that the password is changed again. Let's just do that one more time for good measure so that you can see it in action. Get the Safeguard UI back up here. Change the password again using the UI. Now that it's completed, let's go back to Jenkins. Run another build 12. Build now. Let's go to that build output. Open it up. Look at the console output. And there it is. It's changed again. So Safeguard is actively managing that password and it's being updated by Secrets Broker. For this demo, I'm using an Azure VM again through a Safeguard session. I'm logged in through SPS one, which is publicly hosted on Azure with IP restrictions. But I'm accessing this Win 10 one VM that is on a private network with no public IP address in Azure. This is a great way to securely access VMs in the cloud. In this demo, I'm going to be showing how to use the command line to configure Azure containers and Secrets Broker to demonstrate some of the techniques you might use to automate some DevOps scenarios. So let's start by getting logged into Azure from the Azure CLI. OK, once we are logged in, let's make sure to select the right subscription that has my network and resource group set up. Now, we are going to be using the Azure CLI to deploy HashiCorp vault to Azure running in a Docker container. You can see from the command that I just need to select the Docker image I want to run, the network and subnet, and expose the port that I'm going to be using to access vault. That command takes about a minute to run. Then, I can go back to the Azure portal to see the container running in my environment. Make sure that the container status says running. And using the IP, I can access the vault UI on port 8200 that I exposed earlier. As you can see, vault wants me to log in. To get the root token for vault, I will view the container log, which is easy from the Azure portal. I'll just scroll down to find that and copy it to my clipboard. Heading back over to the vault UI, we can log in and check out the initial setup. As you can see, the default secret key value engine is configured but there's nothing in there. But while I have that token on my clipboard, I'm going to go ahead and add it to Safeguard so that I can use it later for my vault account in the Secrets Broker. I can just do that by manually setting the password for an account. Now, let's head back over to the command line where we can use a very similar Azure CLI command to deploy Secrets Broker. The image name for Secrets Broker is Safeguard-DevOps. And the port we are going to expose is 4443. It takes a minute for the container to deploy to Azure. Let's use the portal to watch for it to be ready. If it says pending, we can just refresh until it says running. Now, using the IP address, we can use the web browser to connect to the Secrets Broker web API using the Swagger page. All of the functionality of Secrets Broker is available via the web API. And the automation tools we're going to use later in this demo are written against this API. So let's head over to the Secrets Broker GitHub page to look at some of those automation tools. The Seekers Broker project is called Safeguard DevOps Service, along with the service we built a PowerShell module that can be used for administration and automation. The module is easy to install from the PowerShell gallery. There is also a samples directory where we will publish Secrets Broker automation examples. This is the script that we are going to use in this demo. Its purpose is to completely configure a Secrets Broker to push secrets to a HashiCorp vault. Back on the command line, you can see that I have the script and a client certificate in my current directory. The client certificate is going to be used for secure communications between Secrets Broker and Safeguard. Now, let's call the script. Looking at some of these parameters, you can see that I'm specifying the location of the Secrets Broker in HashiCorp vault, including the ports. This next line provides an admin connection for pairing Secrets Broker with a Safeguard appliance in my environment. The same Safeguard appliance that I'm using to create this RDP session. That is followed by a client certificate file path and password. I'm also specifying the vault account that I stored the route token in earlier and a Safeguard asset account to be synced through the plug in to the HashiCorp vault. Just a prompt for my admin password. And then, we can just watch it run. The script does all the hard work to get Secrets Broker communicating with Safeguard so that it can watch for password changes. It also configures a plug in that can talk to the HashiCorp vault we deployed. As you can see, the latest version of the plug in was downloaded from GitHub, where it is published as a release asset. So now, let's test it out. First, we need to connect to Safeguard using PowerShell from the command line. Just need to type my password. Now that I'm connected to Safeguard, I can use any of the Safeguard PowerShell Command-lets to control Safeguard. Let's use one to change the password of that account that Secrets Broker is watching. I'll just type that in there, set it running, and watch the progress as the password is changed. Command-let shows a little bit of progress and it's done. Now, if you go back up to the vault UI in the browser again, you can see that the secret engine is no longer empty and that there is the password there from Safeguard. If I head back to the command line, I can run another password change to make sure it updates in vault again. As you can see, there's a new version of the secret and the new password is there. One more thing to show is how to connect secrets program from PowerShell. The SG DevOps module provides a connect Command-let that actually reuses my Safeguard connection because Secrets Broker trusts Safeguard for authentication and identity. I'll just run a test command here and then show you the list of Command-lets that are used to implement the script that we saw today.