Turbot Guardrails Azure demo

Disclaimer: Automated Transcript

Hello! In today's session we're going to review Turbot's Azure controls and we'll demo it through our Turbot console, showcase some of our features and activity happening in real time, and our CIS overlays looking at Azure control adherence.

[00:00:22] The Turbot console here is just one of the many ways you can interact with Turbot. We're a GraphQL API backend so any information you're going to see here in the GUI or the console could be queried or mutated from an API. We're also a provider with Terraform so you could also interact with Turbot that way. In today's demo we're going to go through the Turbot console. Before we get started, I'll also call out that Turbot can be integrated with one or many directories, so anything SAML or LDAP based. I'm going to personally login with my google authentication, my turbot.com credentials. I already did MFA this morning so I'm just going to hop back into my session. Any directory provider that you integrate with Turbot integrates with the MFA you have set up with that provider.

[00:01:10] Now when I authenticate as myself, I land into a homepage that showcases my control summary across multi-cloud, I can also see some favorited parts of my hierarchy. As a quick win, you can see how easy it is to login to my Amazon, Azure or Google account/project/subscription. I'll talk first about the hierarchy within Turbot. Here I just jumped into a folder called Lee's Demo Account. Folders within Turbot give you the ability to set up an organizational hierarchy that can be based on either business units, environment types, cloud providers, really, it's defined completely by the customer. Think of it like folders on your computer - you can set up any number of folders, subfolders, then what you're associating to those folders are cloud accounts. In this example I have multiple clouds within one structure which is then part of a broader organizational structure with multiple different folders and you can see the other Azure subscriptions, Google projects, Amazon accounts, etc.

[00:02:22] Within this I can drill further into my Azure subscription, see my resources that are at the global tier, the providers that are registered, then drill into my resource groups. In this example I'm drilling into my developer resource group and see the components within that. Whatever level I'm at in the hierarchy, I can always see my activities, my controls, my policies that are set at that level or below, and the resources within. So as an example, just browsing this resource hierarchy, if I go to my resources tab, I can see all the resources that live within that resource group, the type, click each one, I can filter my search, I can go further and see my network components, my NSGs, my network interface, VNETs, etc. That's the same use case no matter where I am in the hierarchy; I'll have that same type of view. If I go up to the subscription level, now I'll see a broader set of resources because it's looking across the sub, not just that one resource group. Or if I go up to the Sales organization, I can see all my components, then I could drill back into Azure, see a broader list of resources across the subscriptions as part of this organizational structure.

[00:03:56] This gives you the ability to browse your inventory, but probably more important is to see that inventory and how well it's adhering to policy. The adherence of your controls. Whether that be in an external perspective of security benchmarks like CIS - you can take a look to see how you're adhering to CIS Controls across different components such as your storage, for example, which is Section 3 of that report. Looking specifically at Section 301. Here I'm still filtered on that Sales organization looking at Azure CIS Version 1 of those controls. I can see all my storage accounts that are impacted by Section 301. If I wanted to get a feel for what those resources are, I can just group by resource type and see these are storage accounts associated with Section 301. If I wanted to take a broader look and see how Section 301 relates to CIS Controls Version 7 which is actually a broader section, I can see it aligns to Section 404 to encrypt sensitive information in transit. So, you can see there's a lot of easy ways to manipulate and filter the view here so you can get to the information you're looking for.

[00:05:17] In this one example, I have bobdemoazstorage created on July 2nd, 2020. I can see the history of how it's been moving from when it was first created then it alarmed because encryption in transit wasn't in place - Turbot had alarmed and then moved it to okay because it corrected the issue. Within Turbot you can set policies that will prevent issues from happening but also correct them in real time. Drilling all the way down to this particular storage account, I can see the raw CMDB entry of even things down to allowing public access on blob storage to what the access tier configurations are, what kind of storage it is, etc. I can see all the configurations at my fingertips. But also, I can pull out key information like the tags, other comparisons around the storage account, I can see the audit trail, etc. In this example here, later on after the bucket was created, Bob had come in and looks like he removed one of the key value pairs of Department: Sales and changed it to Department: Marketing. Turbot didn't like this because the policies are set up, so because the tags aren't set correctly, Turbot alarmed but then updated the tags and the CMDB was updated along the way so I can see what Turbot did to remove the Marketing key value pair and replace it with Sales, then Turbot verified that everything was okay.

[00:07:07] This is all happening within quick workflows to verify or to detect any changes in the environment then evaluate what is wrong with the change. So, the above example may have been an okay change, but in this example, it was not, so it moved to alarm. Then if Turbot is set to enforce mode, we would then update the tags in this example, update the CMDB, then verify everything's okay. That's essentially what's happening for any type of resource. Whether it's network security groups, an Amazon S3 bucket or Google storage bucket, regardless of the cloud provider or service, Turbot is in this zone of real-time discovery and reporting or discovery and correction, depending on the policies you have set.

[00:07:56] So even here, looking at other changes that have happened, like Bob had updated the storage account to remove encryption in transit, Turbot then set that back, then things moved to an okay state, even for Section 301 of the CIS report and also the policy to enforce encryption in transit.

[00:08:15] All of this is happening in real-time, the overlays in CIS are in real time, from a reporting standpoint the CMDB is updated instantly. Turbot takes care of the change over time. So just in the life of this storage account just since this morning, there's been 106 activities that have happened in its lifecycle. Going all the way back to its inception, you can see a lot of activity has happened here. Here where Bob created the storage account, Turbot captured the creation and then started evaluating the creation and setting policies, orienting itself on the conditions of that environment. So, there might be conditions based on the region or based on the actor who created the resource, or if it has certain tagging configurations on it - that might dictate different policies you set, and then Turbot reacts. Turbot will orient and calculate the policies that need to be enforced, then will start running the controls and start alarming or marking things okay. Over time things in this bucket got corrected as users continued to make changes to things like access tier, tags, etc.

[00:09:45] From a policy standpoint, let's go back to Lee's Account. I'll remove some of the filters, go back to that subscription. There are a couple different ways to set policies as we will see. Right now, I'm back on my subscription looking at my controls. I could go to the policies tab and start setting policies from here, or I could start setting policies on a resource instead of it being on a higher level - for example just go directly to the bucket we were just looking at - just a quick find right here I'm look up the bobdemoazstorage that was created and now I'm positioned right onto this particular resource. Similarly to screens before, even down to a particular storage account, I can see the CMDB entry and the overview, the controls particular to this resource as well as the policies.

[00:10:53] I'll just pick a simple policy - Access Tier - now I've drilled into a very particular storage account policy called Access Tier (whether you move to Hot or Cold). I am looking at Bob Storage Account overlaid with the Access Tier policy and I can see that at the Sales organization I'm enforcing this policy that inherits all the way down the hierarchy. It inherits all the way down to Lee's Demo Folder, the subscription, the resource group that this resource is in, and the particular resource. When I created the storage account, Turbot evaluated based on the policy above as an ancestor, above the descendant. It calculated that it must enforce a Hot tier onto that storage account. Nothing was done to set it after the storage account was created, it was just automatically inherited.

[00:11:54] But it's really easy to set policies, so if I wanted to change that logic - let's say I don't care about Access Tier - well you can simply skip Access Tier. You can skip it at the individual resource level, you can also set it at different tiers of the hierarchy. Maybe I'll say Skip Access Tier, or I'll just Check to see if it's Cool or Hot, or I actually do the enforcement to enforce whether it's Cool or it's Hot (which is exactly what the policy was that we saw). So, there's different precedents that you can set as well. As a cloud team organization or a security ops organization you can set policies to be required and they're mandated down the hierarchy, then your application teams have to come to you for exceptions to the rule. You can also recommend defaults. Maybe in lower environments you recommend that things are set to Hot, but you can change it as you see fit. You can annotate why you're setting the policy or exception; you can also expire those policies on set periods of time or custom periods of time. It gives you a really simple user interface to be very powerful in that policy setting enforcement mandates across your environment.

[00:13:22] Now, there's different types of policies that can be set. Here within the actual policy that's set is an advanced view. You can simply say either Skip, Check, Enforce, but we also have an advanced calculated mode that sets conditions on the resource. In this example it's running a GraphQL query to pull in some information from the CMDB. It's saying for the storage account names and tags - I'm going to bring that down into a template for this example - it's saying if the storage account name starts with bobdemoaztemp, then enforce Cool on the Access Tier or if it has this tag called test-temp, then also enforce Cool. But if it doesn't meet those conditions, then enforce it to be Hot.

[00:14:25] For any type of if/else statement, you can look up and correlate other information from different resources to make the decision or calculate the reasoning for what the policy might be. So, it becomes a very powerful conditional logic that you can set on top of our pre-canned policies for this type of control. In this example because it didn't meet those conditions, that's why it enforced Hot in this particular storage account.

[00:14:58] Now there are other ways to set policies outside of the pre-canned policies which are Skip, Check, Enforce. We support hundreds of cloud services, we have thousands of policies that are already out-of-the-box, you saw those calculated policies where you can set conditions wrapped around it for your nuances. But we also have a way to set policies with your Terraform stacks. So those Terraform stacks - you can set very similar to the way you would set policies - you can also set your Terraform HCL code as a policy and Turbot will enforce those Terraform stacks across your environment.

[00:15:41] In this example I'm going to show a stack that's already setup, where the stack is deploying across my resource groups in this subscription and it's deploying a NSG with this particular name across the location of the resource group so it's looking up the location and bringing it down into the logic (just variable from the CMDB) and this example is pure Terraform of setting that particular security rule for an ingress or an egress and tagging it etc., so it's all Terraform out of the box that you can set. Here I've set that Terraform stack and it deployed it across all of my resource groups.

[00:16:43] As an example, just recently what I changed here (and I can see my diff history of my stack changes) was the network security group priority from 101 to 102 and Turbot then configured all the stacks across. So, if I look up a Turbot NSG Terraform and if I just pick one here from the dev tier, the dev resource group, I can see the activity of what had happened. So, as Bob set the policy, Turbot came in and updated the security group. This is an example where it updated the change in priority from 101 to 102 and then everything is marked as okay. So, your Terraform stack just becomes the policy being enforced by Turbot.

[00:17:43] And the great thing about this type of configuration is that even if someone came in outside of the pipeline, if they were directly in the Azure portal, Turbot would still take action to correct it. As an example here, Bob had made changes directly against the network security group then Turbot came in and corrected the resource directly based on your Terraform stack. Essentially Turbot is managing State of your stack, so it doesn't matter how changes or deployments are occurring, Turbot is going to react just like our general guardrails but in this case, it's based off of your Terraform configurations that Turbot's enforcing.

[00:18:34] I'll also show some additional features around our permission model. On the top bar I'll navigate to Permissions and go to our account structure. Turbot is also an identity engine and we can help enforce role-based access controls or RBAC across your multi-cloud environment. Specifically pertaining to Azure, we have very similar role definitions to Amazon and Google and other scopes, where we have consistent logic on who's an admin, power user, operators, read-only, metadata viewer, etc. So, there are very consistent role definitions agnostically across each cloud provider but also per service. So, an Azure Storage Account admin would have a very similar risk profile and rights to an Amazon 3S Bucket admin. We help keep this consistent logic with our back controls which then get deployed across your subscriptions. It's completely optional to use what we offer out-of-the-box, but it also gives you the ability to modify our logic as well as bring in your own custom roles that Turbot can manage. Regardless of what you choose, Turbot provides a very simple interface to associate multi-cloud role-based access controls.

[00:20:08] Here's an example where Bob, coming in from this Google authentication directory - has rights across many different layers of my hierarchy with Turbot permissions (Turbot has its own role-based access controls with Amazon, Azure, Google) and in this case I'm an Azure owner as well as an Azure superuser. If I wanted to add additional permissions into the environment, let's say I wanted to add Cody from the directory and give him Azure admin rights to this particular hierarchy, I could simply look up the user (we also integrate with Groups so you can look up the Group) and assign the role-based access control. You can then activate that for immediate use (deploy immediately) or choose to expire it at any point in time. You might end up giving out rights to Cody for Azure admin and activating it now for immediate use, then expire it within a certain amount of time. You could choose from the pre-canned options for time or customize how much time he should have access. With Turbot, you can use time-based role-based access controls with activating now or later, it allows you to pre-approve roles in the environment. In this use case I might say that Cody's pre-approved to be an Azure admin - we won't activate it now - but he's going to have pre-approval for the next 72 hours to activate within that window. There are different combinations of identity management that Turbot can help with, but they're completely optional as to how you want to leverage Turbot in your environment.

[00:21:55] That concludes today's session. Feel free to reach out to us at turbot.com/connect and we'd be happy to handle a curated demo for you. Thanks!

If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!