We are just now beginning an Identity Now project. From prior projects/experience, I have used DevOps (Version control, CI/CD, etc.) and things like Terraform, PowerShell/Bash and Restful APIs to manage systems.
Are any of these concepts possible with IDN?
I would preferably like to have a more structured/formalized promote to production process for our Production IDN instance… i.e. Changes are deployed into our production IDN via some sort of release process (hopefully using a script, automation, etc.).
Changes come from version control, and prior to deployment can be compared to last known good configurations to easily see what is being changed, or rolled back easily to prior versions if issues are found.
Are there ways to use these sort of modern development practices with IDN?
We have the SaaS Configuration Import/Export APIs that allow for promoting a limited set of objects from one tenant to another. These APIs are the most direct means of configuration as code that we currently have. Apart from the SP Config APIs, you might be able to leverage other APIs in our catalog to do promotions.
I’ve never used Terraform myself, but I thought it was meant to be infrastructure as code. Given that SailPoint manages your IDN tenants, I’m not sure how applicable Terraform would be for managing tenant configuration. However, I’m curious to hear more of your thoughts on what configuration options in IDN you want to manage with tools like version control and configuration as code.
I wasn’t suggesting Terraform as the solution, just as a conceptual idea on how to reliably get configuration out to a given environment.
I am very new to sailpoint (I only got our instances a few days ago). So my vernacular may be off.
Generally, I want to be doing any testing of configuration/settings in a nonprod environment, serialize/capture that configuration change, persist it in version control (JSON is fine), and then apply it / Deserialize that into the production environment (possibly swapping in parameterized values if they have to change between nonprod/prod).
This would go along with a “No prod configuration changes via Portal clicking general rule” we all follow (as our production configuration changes came from that configuration as code process, not via clicking in the portal)
Right now, I am struggling a little to understand how promote to production is done in IDN, it sounds like click in non prod, document, then follow the document / click again in prod…
Yes, I believe most administrators go the route of manually updating prod with changes they documented in stage, or they have curated their own tools to accomplish this via our APIs. Our professional services team might also have some tools they use to help with this. @hari_patel , do you happen to know of any tools that assist with migrating IDN configuration from stage to prod?
if that is the case, then I agree with Mark Cheek’s comments above. Platform support for this sort of concept would be very nice to have.
“Make sure you click the same way!” sounds a little strange in this day and age to be honest… (or maybe people don’t use a IDN staging/nonprod instance as much as I think they would, and they just work once only in production?)
A good example of how this is managed is a tool like ServiceNow. In your lower environments, you create an item called an “Update Set”.
Each configuration change you make is logged in a table and linked to the update set you created. When you are done, you close your update set.
In the upper environment, you can load an update set from the other tenant where it analyzes the changes you made to check for issues or collisions and then allows you to commit all the changes you made.
It’s an extremely useful way of ensuring the changes you make in each environment are the same
With several IdentityNow projects under my belt, this is till the biggest struggle. We’ve been trying to ‘automate’ as much of our config changes as possible, using GIT the (not supported) identitynow-io tool, deploying changes via separate API calls and indeed manual changes via the UI. This is imho still the biggest pain in dealing with complex environments.
We will be using Azure DevOps for things like mapping tables, access segments, etc. Make a change to the JSON in DevOps, promote it to production, and it runs a Powershell script to POST the changes via the IDN API.
I am still hoping that SailPoint recognizes these concepts as an opportunity to improve the TCO of IDN and builds out not only easier to use native capabilities but also best practices/operational guidance. (“Here’s how we think you should use our product…”)
I guarantee the core IDN platform developers are using best practices/guidance (version control/change sets/merging in change sets) in helping deliver a stable and regularly enhanced IDN platform. It would be nice to have these things be used not only on the product creation side, but also the product usage side.
Until SailPoint does do this though, it is probably something we have to try to do ourselves.
@danielkeisling could you share some thoughts on your plans? I am new to SailPoint, but in a previous life was an Azure DevOps developer and solution architect…
Are you only using this process for certain IDN entities, that don’t need to be eventually brought back into Azure devOps/version control? What you have in source control is ‘always your starting point’? Or do you have an import into AZDO process?
What’s your high level process? How many environments do you have? are you using the portal UX as the lowest dev env, exporting JSON out, performing any cleansing/transformation activities to parameterize/strip out environmental values from the JSON, and then pushing that through an AZDO rest pipeline to a staging/test server (having the pipeline supply the environmental values); verifying the change work as expected, and then deploying the same JSON to production?
We’re still in the design phase so we haven’t worked out the actual process yet, but yes, we’ll use it only for certain entities - access profiles that have over 250 entitlements (that’s the limit in the UI), governance groups, and entities that can only be updated via the API (e.g., transforms). DevOps will be the source of truth for those entities. We have 3 environments, so I envision we made the change in the repo, push to Sandbox, verify all is well, then promote into TEST, verify, then on to PROD.
And don’t get me started on the Cloud Rule deployment process
Our production cutover has come to a complete halt while we wait on a rule to be deployed by support. Not to mention they had to make sure we had enough ES hours to even do the work.
This is something that needs to change. Asking your customers to pay for professional services to review and deploy configuration work we did on our own is a total grift.
