About a month ago, my good colleague, Angelo Nappi, wrote a great post on the Importance of Credential Management outlining some important points around managing credentials securely. It got me thinking about my own experiences working in the field of Discovery... sometimes I do come across customers who do not want to store credentials in the ServiceNow cloud instance due to compliance or internal security policies. In such occasions, I'd offer External credential storage feature to the rescue. Unfortunately, it would require custom integration with any vault or keystore. Over time, however, we did notice a trend... CyberArk was the name that kept coming up! After some internal discussion, our great folks in Development have done it! It is now supported as a native integration starting in the Geneva release! Hooray!
Without further ado, Let's dive right into it. Here's a reference diagram for the CyberArk integration.
The entire integration is built upon the External storage credential framework that I had mentioned earlier, so the mechanism to operate it remains the same, but we've essentially got ourselves a turn-key solution for CyberArk. Here are some details on how this works...
You would create stub credential records from the instance in the external storage view. Notice you wouldn't need to fill in the username and password. Instead, you would check the "External Storage" checkbox and specify a "credential ID" attribute, which becomes the marker to specify which credential from the vault should be retrieved. The "name" attribute, as always, is used for human manageability so that one could easily understand the purpose of the credential.
This also means that you have the choice to specify which credentials should come from the vault; this comes in handy when you need something quickly verified without having to go through the complete setup with the vault. Now let's talk about how the MID server uses the credentials.
The MID server downloads the credentials when it needs them for the purpose of Discovery, Service Mapping or Orchestration; and resolves the credentials that requires username/password from the vault at run time. From the standpoint of how MID severs communicate with various IP targets through different protocols like SSH, SNMP, WMI etc, credential retrieval is really orthogonal in that process. The MID server is simply deciding where to get the actual values for the credentials and that's the only difference. I have come across some customers who are hesitant in going forward with playing with ITOM products simply because the vault was not ready yet; Now, barring strong compliance issues, there's no technical reason to wait because it's literally just moving the credentials details from one one place to another (cloud to vault); everything else stays the same. Anyways, let's get back to CyberArk...
With this being a native integration, you can configure it fairly easily; I won't go through all the nitty gritty details of setting this up because it's outlined in our CyberArk integration configuration, but let me talk about some of the key things to pay attention to as you look at the reference diagram above.
1. Enable the "External Credential Storage" plugin by contacting HI. You'll need to enable this plugin to use it, but don't worry, it's free!
2. CyberArk AIM agent is required for each MID server. This means that you must have purchased the AIM module and have enough licenses to install them on all the MID servers that require the integration.
3. MID sever automatically takes care of the rotated password. Since the AIM agent takes cares of the actual communication to the vault; this also ensures that when the password is rotated in the CyberArk vault, the MID server will always get the updated password since it never caches the password it gets from CyberArk.
That's pretty much what I can think of at the moment, please feel free to comment or post questions. One thing I do want to mention is that SNMPv3 credential will not work with CyberArk. This isn't on us (ServiceNow); we absolutely support SNMPv3 credentials. This is due to CyberArk doesn't have support for SNMPv3 credential type. We're hoping this will change in the future so we can provide the proper support.
Lastly, if you're interested in creating your own external storage credential integration to other vault/keystores, my great colleague Anders Henriksson recently wrote about his experience in How to implement Thycotic Secret Server as an External Credential Store. Check it out!
10 Comments
