One Identity Safeguard Secrets Broker for DevOps Jenkins Integration

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 plugins. So this demo is actually recorded from a safeguard session that I'm doing into a Windows desktop running up in Azure. I'm going to install the Secrets broker from the MSI here on this machine. My SVP and SPS appliances are also running up in Azure, and Safeguard is granting me secure access into that Azure environment. The Secrets broker MSI Installer takes a few moments. And when you're finished, I will have a Secrets broker running as a Windows service on this VM. I'll show you a sneak peek preview of the [? Win ?] Secrets broker web UI that will be released later this year by navigating to local host on port 443. I 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 that client certificate, which would be the most secure way. Or I can just upload a PFX PKCS 12 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 PKCS 12 file. Now let's give Secrets broker a minute to process that and use it to establish communications with SPP. There we go. Now Secrets broker uses plugins 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 plugin is installed, we need to edit its configuration. Each Secrets broker plugin can have a plug-in configuration detailed specific to communicating with that credential store. Here we are 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 log in username. And in this case, it's just "user". Because we don't want to hard code a password in our plugin configuration. Each plugin can also specify a vault account, 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 into Jenkins. You 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 already know and love to access this PAM Secret that is actively being rotated by Safeguard. So here they have the normal credential 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 that Jenkins doesn't try to mask them out of the console log. So let's just take a look at the latest build outputs so you can see what the Siebel password value was the last time this job was run. So there's the username, 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. Whoops. My platform task UI is over here on the other monitor. Let me grab that and bring it over. It's already done. So let's jump back into Jenkins and start a 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.