so my name is joe offenberg uh about a month or so ago i provided uh an overview and a demonstration of our devops con config product and what i'm going to do today is actually take it a step further we're going to talk about the devops config a little bit but more about the integration with uh global uh governance risk and compliance product and uh so you know what we'll do is just a quick recap on devops config and what it does if you didn't see the first uh webinar so the idea here first i got to give you the safe harbor slide right so i might be making some statements about the future of the product and this allows me to do that without it becoming a contractual obligation all right now um there are some other uh housekeeping slides here uh the uh there's a there's a whole series of these live on service now you can you can you can see the schedule here uh if there's more you're interested in okay and then some additional housekeeping bullet points here please stay on you we're going to do a q a after the presentation but you know in the meantime you could add some questions to the chat and that will allow maybe some of my colleagues to jump in and answer them but we'll do some live q a at the end and then the session will be recorded and then posted in the forum and then at the end of the session if you'd be so kind to fill out a brief survey uh give us some feedback on the session and what other sessions you might be interested in okay so now config data is uh so we covered this last time but just to recap what is the scope of configuration data so i came from uh an acquisition of a company called sweevo and we had a config data management platform right so config data management is now inside of service now as devops config and what it's really all about is managing configuration data primarily in the devops pipeline so this is uh mostly you know infrastructure is code using tools like kubernetes or terraform or hansible to provision environments in the pipeline including up to up into uh production environments and this config data could be anything from application configuration data such as uh you know feature toggles and api keys and connection strings sometimes the release data as far as dependencies between different applications and different libraries and so on and so forth as the data is moved into different environments you're going to have environment specific config data and that's uh important that you understand how config data deviates from one environment to the next but the bulk of config data the most voluminous of the config data is the infrastructure right and this is the provisioning of vm instances the provisioning of uh infrastructure like load balancers and and firewalls and so on and so forth so when we look at you know why this is a problem it's because of a few things one is uh there's an explosion of cloud provisioning of resources right so more and more moving from on-premise data centers to cloud data centers so that creates uh additional requirements for for for config data being managed in devops pipelines and the proliferation of agile the agile methodology where you're making small incremental changes continuously this also applies to devops too so you're changing not only do you have more configuration data because you're in the cloud but you're changing it more frequently right and by adopting technologies like infrastructures code you have additional complexities to this configurator more and more of this config data is now being built in the pipeline deploying immutable infrastructure that doesn't change ephemeral infrastructure that's only temporary so that means if you wanted to actually change something you would destroy it because it's just a cloud resource and then redeploy it with some new settings right and so that's how more and more of this is happening as we move forward in this new world so when we look at config data within devops config we understand that there are actually four states of the config data there's the config data you define in the infrastructure as code that you defined before you deploy it and that could basically take a template like a terraform template and fill it in with some variables to deploy it in a certain environment once it's deployed you might have actually different settings than what the infrastructure called for what the template calls for you might have deployment specific settings and so there's the definition and then there's the deployed state and then of course as things have been deployed somebody might go and actually change it so we call this the discover state we want to be able to discover uh changes that are happening in the environment after things are deployed and then the fourth state and this is the most important is the history what was the state of this particular environment two weeks ago two months ago yesterday before we had this deployment so being able to track all of this uh requires uh you know a new way to organize data a way that the cmdb itself by itself wasn't really built for right because this is data that's changing more frequently and the only way to stay on top of it is by integrating with the devops pipelines and the git repositories and the um uh you know and and all the devops tools where this data lives and bringing that into the servicenow platform in real time and that's what we're doing with that launch config so that's that's a quick overview of what we covered on the last call we went into a demo in detail on that so if you do have a chance go back and look at that and you'll have some more information about the uh devops config platform now what are we talking about today well uh we're talking about governance right and what that means is uh because more and more of the infrastructure uh is is being deployed this way we need to shift left the governance of this infrastructure that means we need to actually catch uh issues that might deviate from policies earlier on uh in the pipeline in the dev environments in the testing environments right so we have to apply governance policy in these in these environments so how do we do this well uh first we um you know we we have to take the the governance frameworks that uh that our governance and risk and compliance tool does so well mapping those frameworks to control points and so on uh understanding the risk understanding what actually needs to be uh managed right and then uh taking the devops policies specific policies for saying hey this particular key value pair this particular setting and a config file now mapping it to those policies so i'll give you an example you might have a framework that says you have to lock down what email domains you send notifications to like it notifications right you can only send them internally so we will actually have a policy that looks in config files for those email domains to make sure that those domains are specifically listed and you don't have additional domains uh another policy we might have is something uh for enforcing uh certificate validation you know developers you know often like to turn off certificate validation in the dev environments right why do they do this well because it's sometimes it's difficult for developers to get valid certificates they spin up a new resource especially a cloud resource it has a new name and a funny domain and they can't get a proper certificate for it so they turn off certificate validation well now they leave that setting turned off when they deployed a production and we need to be able to catch that right so devops config is very good at catching that but there's actually a policy and a governance framework that enforced that that that control needs to map up to and that's what we're doing here we're mapping the low-level uh settings and the controls on those settings up to those policies so when there is an issue um you know we can see what policy is impacted by that okay so this is actually shifting left to controls being able to validate these settings before uh they leave development right so the developer will check it into git change a setting and we want to catch it before it's deployed to the next environment and we do this we have a new capability called the policy is code engine that means the actual policy that we're using to enforce that control is written in javascript right and that makes it very devops friendly that means you can you know you can you can store it it can get if you wanted to and you can use it uh you know it makes it more deployable and more portable and easier for uh developers to you know to create the code in any way they uh they choose to okay and the other part of this is a config data model that's now you know this is the technology that we acquired in the swingle acquisition a couple of years ago again that's the acquisition that's where i came from and this this data model is a way of organizing config data in a hierarchical way that makes it easy to sort of deduplicate config data to understand the relationships between config data at the component level and then at the application level and so on and so forth so this data model makes it easy to then take snapshots of the config data so as things change you maintain that history remember that's that's one of the states is to track the history and now we actually attach those snapshots to change records in servicenow so as you deploy a change to production the snapshot of that config data is attached so you'll see that as well i can show you a little bit of that in the demonstration okay so we bring this all together and we'll allow you know we allow you to automate the uh control of these uh uh control point objectives right the actual control points are actually automated through the devops uh policy they're about to config policy okay now another scenario we're going to talk about is what happens when you need an exception it's great that you could enforce the policy i could even stop a pipeline from deploying to production uh because it broke one of these policies right but sometimes you need an exception so one of the great things about uh you know governance risk and compliance is that we can we can we can manage those exceptions right so we're going to take those exceptions and manage them in a workflow where the compliance managers can review them can say hey can we allow this to go to production or not maybe there's some uh some you know some really good reasons why we have to allow this exception to take place uh and all of that is tracked and all of that is going to be um you know saved in a transparent way so that the auditors will now have the ability to see uh who approved what exceptions when it was approved why was it approved what was some um you know what was the reasoning behind it and so on and on and so forth so that's what i'm going to show you is uh not just the ability to map the config policy to the controls but also to handle exceptions which you have to be able to do because exceptions will come up okay so this is what the demonstration will look like one on the governance side you adopt control objectives right and these could be you know there are a lot of frameworks out there there's cobit there's uh uh you know sox compliance there's gdpr compliance right and uh devops folks now have to create config validation policy that match up to those objectives right uh you know and make sure that developers have the correct access or don't have the correct or don't have the access that they need or that they might uh you know to allow them to do certain things to enforce like maker checker moves that a lot of these policies have where somebody has to make a change and as well as somebody has to check that before it moves to production these are you know there's quite a few of these policies uh and then if someone violates a config validation policy see let's say a developer makes a change to a setting now they're deploying that config file to production um you know if it violates it we have to be able to stop it but also allow them to request an exception and that's what i'm going to show you and then if the exception is is okay if they have good reason for it we can approve and reject it and you know most importantly all of this gets logged for the auditors all of this is tracked there's an approval process there's a workflow around it and and nothing will get missed here um i think uh i'm going to do start with the demo next but maybe it would be a good time to check if there are any questions in the chat before i jump into the demo does anybody understand the concept here i'll take a look at the chat myself let's see okay so unless i'm missing something i don't see any questions so i am going to go right into the demo here um so in our previous session we had this uh this jenkins uh pipeline and as you can see what we do is we retrieve the sources from git that means you know we have to developers make all the changes uh we kick off a pipeline we have an environment where we build the application uh we also validate the code this is something we've been doing for many years what's new is now we're also validating the configuration so we're applying the same level of scrutiny to the application configuration that we've been doing for many years with the code like unit testing and some static code analysis here we upload it to servicenow and uh we're going to validate it if it all looks good we publish what's uh essentially an artifact that can now be deployed to the various environments but here we're going to export the configuration and then we're going to do some functional testing in another environment eventually that makes its way to production of course if we do go to production we need a change record right that change record has all the information including that config data snapshot that i've taken over here with the new config changes right so now i have a config data snapshot that's attached to that change record okay so what happens if i make a change so here's a scenario where i've updated a cloud formation template to deploy a database here in a different region so i made this change and the change actually basically says in the previous um what i did was i updated this config file i changed it from eu central to u.s heat okay so the database used to be deployed in the eu uh but now i'm deploying it to us then uh why am i doing this well perhaps there is a um it could be a power issue in the data center in the eu you know there could be some power shortages right that's not a unrealistic scenario uh given the current geopolitical situation so we have to now start redeploying some resources to a us data center right so that's what i'm doing here however this eu database could potentially have eu customer data in it right so this is a violation of a gdpr uh policy right so gdpr is uh is is a framework for managing um data and privacy of that data in the eu but you know many american companies have to deal with this as well as they are you know globally deploying resources all over the world in the cloud right so now how do we know this mapping exists well within uh servicenow and i'm going to show you the compliance workspace here [Music] what you'll see is that when we look at a control objective and i'll find one here and i'll find that gdpr one we can actually find the um the mapping to the config data policy right and if you saw on the previous demo uh here's the config data policy here and this is where we can map and i can add additional policies and map that you know looking at the certificate validator and so on and so on so this is coming directly from the devops config application okay so what happens is when i make that change um [Music] it's going to fail the validation is going to fail right it's going to fail and it's going to tell me hey that particular policy the aws region check uh doesn't allow usc it's looking for the rule says it has to have the eu in the region meaning it has to be deployed in the eu okay so as a developer i have two decisions i can make one of two choices i can go back into this and change it back i can change the config setting back to eu however if i need to redeploy because of power issues then that doesn't solve that problem right so the other thing i can do is i can request an exception right so from this um okay so i'm in the compliance workspace now now as a uh let's say as a devops person i can go into uh devops config workspace here and i can find uh that particular validation that failed so this is the globex application when that pipeline ran it there was a snapshot that was taken right that snapshot failed validation okay so we'll see the validation results here and it failed so what i can do is i can now request an exception okay so this is basically what happened inside of devops config in the uh jenkins pipeline it shows up exists so this is the way uh all the developers see it they say they can't you know they can't deploy to production because of this issue so as a as a devops person i can request that exception so i'll go ahead and do that here here is the refresh this i'll get that snapshot back okay so when i request the exception it brings me up a window here and i'm going to say why well i'll say power issues and eu data center right so i'm going to go ahead and go i'm going to go ahead and make that request i can give it an end date let's say let's give it 30 days to work itself out and this will put a policy exception specifically on this policy in this environment i'm not asking for a global policy exception being very specific that in the globex product environment i need to put the database in the us and i'm making that request so this request now goes in and in the now it kicks off a workflow on the compliance side right so if we look here at the [Music] policy exception list that's going to show up here if i sort by name okay i see there's is actually a couple here this is the latest one uh and what happens is now as a policy manager there's a workflow right so i have to analyze it i have to look at some details okay uh power issues in the data center that's significant um you know does policy allow me to uh override that well we're going to we're going to send this off to an approver and we're going to actually set the risk rating rating as let's say medium or in this case maybe it's low because we're not going to impact too much by running it in a different data center and i'll go ahead and now save this and once all the risk information is filled out i then get this button here where i can request approval if the risk isn't analyzed and assessed we won't be able to be requested so go ahead and request the approval now so now this goes into you know the approval workflow somebody has to approve this so uh if i bring up the list here i see okay frank worries the approver i'm going to go ahead and click on this and we're going to say okay let's say frank comes in and approves this we'll save this record is now approved okay so now we have a policy exception that's approved so the idea being if i were to run this again and first i'll make another let's say a basic change to the um to the configuration of that template right i'm just going to change a port number so uh i could run the pipeline again the pipeline's not going to be happening if i change it without actually if i run it without actually changing anything so if you've seen uh devops change velocity what i'm doing here is i'm linking this commit to a jira work item that's what this notation is here but that's that's for a whole different demo i'm integrating with jira i'm gonna um okay so i updated the database port i'll go ahead and prove it but i left i left the aws region as usb so i didn't change that so what i'm expecting now is if i run my pipeline now that i committed that we're going to go ahead and limit the pipeline again uh i would expect this now to be okay right because i had that exception and so as a developer i don't need to know about the you know what's happening in service now i stay in my tools and i just know that hey i need a an exception to a policy here to get this deployed to production uh the devops folks will handle that request the compliance folks will review and analyze it and decide if this is okay and once that all goes into place i can then make my you know make further changes and then go ahead and run the pipeline again and that's what i'm doing now let's see let's remove it so okay we're uploading the config files the changes i made to the uh the cloud formation uh templates uh we create a new change set so all of this is happening in an automated way through the devops pipeline and then once we're done uploading we'll we'll start the validation process and that's uh where last time we failed right in the previous job we actually failed because of that and the failure showed up as a as a test case right all right and then you know it's very clear why we fit out so if we go ahead now let's see here we go okay so this time it's not red it's yellow we allow the pipeline to continue although we do indicate that hey this isn't 100 perfect um the test case still failed but if we look at the validation step we actually say hey it passed with an exception okay the validation failed but we allow it to go through with an exception that allows the pipeline to continue and that allows the the pipeline to go to production and uh create uh what would be a change record right because the change record has to be there for us to get the production okay so let's see how are we doing i think this takes a minute let's see do we have any questions anything in the chat at this time i guess if there's some feedback that would be useful this is does this conceptually make sense to everybody that's joining we understand uh why we need to validate config files and config settings and also why we need to connect this to uh policy and in grc then system compliance yeah all right so now before we go to uh production we get a change control step we get a new change record okay so if we go and look at the change record what you'll see is we've actually hear this here we've actually attached that pipeline um here to the change record and this is useful right because now i know what actual config data was deployed with this particular change okay i also see the commits from git i see the test summaries i see you know even the software quality scan from sonarcube all of that is part of this change record it's a very comprehensive change record we create automatically it includes all the you know the test results passing if you've seen this demonstration you know that we can take any of these data points and use change approval policies to automatically approve this change right but what i'm going to do is i'm going to go ahead and approve this and now we'll get a record that this was deployed manually once this is approved this will go and reach the implementation stage and that'll be approved okay so now we have a um so that that concludes the uh the integration with the grc right so that's the governance integration but now we have deployed configured so i just wanted to show you give you a taste of some other since we have some time uh give you a taste of some other integrations we have uh with devops config and that's with the service operations workspace right because understanding what's deployed has implications when you're trying to figure out what went wrong you know the first question you always ask is what changed that's one of the major use cases of change management is tying it back to incidents so you can see exactly what changed well because we're automating so much of these change records and you're going to get a lot of change records it becomes really valuable to tie these change records to um you know like in the cnb the cis and the alerts so i'm going to bring up an alert here okay and this alerts okay we haven't had any payment process for the last 15 minutes that's a pretty serious alert and what we can see here is that uh we've determined uh that there's been some changes right recently and these are the probable rupauls based on the changes right this is the probably what we do is we take the latest change and now i'm going to bring up uh the change record that we've seen before but in this record i have attached the config changes right so the actual snapshots i'm taking with devops config i can see them on the timeline i could see here's when i got deal with it and then here's when i took a snapshot here i took a snapshot here there's a bunch of activity over here i can go back you know weeks and see all the snapshots that took place in the timeline so why is that useful well i could also compare i could see into the data model and see all the settings and changes so if i'm looking for a specific setting i could find it in the data model i could do a search and find it here but more importantly i can say just show me everything that changed you know in the most recent change i see okay i changed the region uh from us east uh eu central okay that i'm aware is a compliance issue but that's not what broke the application right i i might have to go back even further um let's say there is performance degradation like two weeks ago you made a change and and you want to see what uh what changed in the last two weeks so well in the last five days but it didn't you know it didn't become an issue until uh recently uh what we can see is the um the snapshots that apply you know and i could i could compare uh from previous snapshots uh all the way up through the target snapshot which is what's been deployed now okay so that is the advantage of this so i get a list of snapshots and go back even further with some snapshots and being able to make comparison between the snapshots within the service operations workspace okay see now i can go back there's a list of all the snapshots i can go back to i can go back several weeks back to august 17th i could run a comparison between what i have in place now and what changed on august 17th because that's that might be the point at where degradation started right performance degradation started and i can see here uh i could see all the different changes and you see that there's the port number change i saw it before but now i also see there's a firewall rule change or hey that's going to be most likely where core is performance degradation somebody changed the firewall and so on and so forth you can figure these things out um okay so let's see do we have any questions uh the approval was in the change record for devops would that not be performed in devops orchestration tool rather than the change record so the way we work it is in the devops orchestration tool that's a good question um the approval is actually uh in the change record but we do link the change record back to the orchestration tool so uh why would we do that well in in we need we need a change record right because we're deploying to production and we need uh and depending on what is impacted by that change right and it could be many things you might have to get different approvers involved also uh we have the ability to say hey um let's say there was an issue with the uh the quality scan right let's say you had a security vulnerability right that might require uh an infosec person to be dynamically added to the approval list so this is something that's you know it's diff it would be very this is something that servicenow and the change management does you know natively you know being able to take these workflows and and you know using decision tables decide who needs to approve what and it's a lot easier to do that in servicenow where you can reference the cndb it could reference the assignment groups of the ci so on and so forth so that's why uh we manage the approval in ci now if you go back further left you might have an approval for a change request right not a change request a pull request that's something you handle in the orchestration that's something you handle in the pipeline but once it reaches production then you need a change request and you need to change requests to food i hope that answers your question uh if this deployment includes downtime impact the downstream application cis are the impacted ci's approval groups added to the change request yeah that could happen i mean that's something that you can handle in the backend integration hub flow so all of this is governed by an integration hub flow and you can decide that you want to go let's say one level away from the ci using the relationship model using the uh using the uh view you have here of of the uh configuration i don't know it's not attached um you should be able to go you know one level or two levels away and see what else is impacted and add those approvals to the approval lists but that's a good question yeah okay are there any more questions all right then i think uh you're gonna wrap it up here let's see if there are no more questions we'll uh you could uh you can end this one early thank you very much thank you for the opportunity to show you uh the devops config again and the integration with irm and the governance risk and compliance and the control point exception use case [Music] for any other questions you can okay one more question before we leave what are the product modules required so what i showed you was the compliance workspace module the service operations workspace module if you want to do that alert immigration where you do the root course analysis and of course on the devops side you need devops config which is which is a product in the and all of these are in the store you get them to the studio through the plug-in installer the previous demo uh the url if i think if we go back to that first slide and you have a list of all of the um all of the if you do a search on google for for service now and this is how i find it i go to intensive uh servicenow live and you'll get a list of all the demos and you have to you have to register if you're not registered and then you'll get a list of all the previous and all the upcoming and the previous one will show recordings okay any more questions devops config is actually part of itsm pro so the question is what are the devops config license requirements uh you get devops config and devops change velocity with itsm pro there's no separate license for it you just have to be part of the 12th level of itsm oh another question does it help with setting preventative controls why is it called left turn well i think we're calling a shift left because that's a like a devops expression a lot of people use to say we're going to try and uh shift as much of the um [Music] the the quality gating and the approvals and the uh you know the idea in devops is to try and fail fast right and if you're going to fail fast you have to put you have to front load a lot of the uh a lot of the quality checks and the gates and so that's where the shift left comes from because if you look at the typical picture of a software development life cycle you have development on the left and then deploying production on the right so what we're doing is shifting everything to the left including the controls on uh on the uh on the devops config settings which has always been part of uh something that you did in operations all the way on the right side so now we shift to left all right cool all right well thank you all and uh i'll see you next time enjoy the rest of the week