Disclaimer: Automated Transcript
Hello, in this session we're going to review the Turbot console as well as features related to Google's Cloud Platform for governance controls. Turbot is a graphQL/API backend so all the information that I'm going to showcase today in the demo, you can query out of the product or your can mutate against it. We're also a provider within terraform so you can manage these configurations in Terraform as well. But in today's session I'm going to showcase the console.
[00:0033] So to get started, a user will be presented with a login screen, you can have set up against Turbot local directories, SAMS-based directories, LDAP-based directories, you can have multiples that you can pool against as well as bind profiles against. In this session I'm going to login with my Google authentication, or my turbot.com credentials. I was already logged in, I'm just going to log back into my session. But if I were logging in for the first time I would go through the SAML MFA process just like any other directory authentication. So here I land into a profile page about myself, I can see a list of all my control summaries across my major components or major parts of my environment. I can see some favorited locations of my organization that I can hop right into, I can log into different cloud environments quickly, but I'm going to focus on my Bob's Demo Account for today's session,
[00:01:26] Right there I just jumped down to my profile page - I'm still authenticated as myself right here - and I hopped into my Bob's Demo Account. And this is actually just a folder that sits within the hierarchy that sits within the Sales organization or the Sales folder which then sits in a global entity called Turbot which has many folders and cloud accounts etc. So in this particular ecosystem I have an Amazon account, a Google projects, Azure subscriptions, kubernetes clusters, Linux hosts that are represented within this hierarchy. In anything within Turbot you can see that direct CMDB entry of that particular resource that you're focused on, you can see all the related activity, the controls which are the health of your policies, your actual policy configurations and settings, your resources and permissions that you have across not only Turbot, but if you're using us for Amazon, Azure, Google, etc permissions, you can also manage that on this screen.
But to get started what i'm going to do is fire off some resources How Turbot picks up those resources within the CMDB Are going to run against those resources. So i'll go into my google project that's related to that - so this is my Bob Demo Project that's referenced in the Turbot screen here.
So we'll go to the browser and I'll create a bucket here. In this example, Bob as a developer in one of his GCP projects, creates a Google storage bucket. Within that, Bob the developer didn't necessarily know what the company policies may be, to maybe enforce versioning within that bucket, certain labels, certain encryption standards, and so all the governance controls that may be set by the organization, as a developer he might not know or might not care what those controls are. And that's where Turbot comes in, is to detect that resource creation or that resource change and then react to those with policies that are going to be enforced. So in that example, I had just created that storage bucket, and Turbot's going to pick that up within the activity, and so that bucket was already picked up and configured by Turbot with those policies. And so I can see this Bob Demo GCP bucket that I just created - and let me just filter right on that - so what that did right there is I just filtered and moved down the hierarchy straight to that particular storage bucket - and I can see all the activities that Turbot took action on.
And so if I go all the way down from the start, Bob created this bucket and once I created that particular storage bucket which was just an empty bucket within the US region, Turbot then fired off a bunch of controls that it was going to set off in the environment based on policies that I had set. Then it's also running some overlays for CIS controls, it's then starting to run those policies and calculate the reasoning behind them, it's then starting to fire off alarms based on the configurations of that bucket, and because I have controls that are also set to enforce, we're also going to see Turbot take action. So not only is Turbot going to alarm that versioning is not enabled, it's also going to set versioning, in this example and update that.
[00:05:29] So I can actually see the diff history of what Turbot actually did, so it not only did versioning and labeling, but at encryption at rest it also updated it to a custom manage key that it automatically created on the developer's behalf. So there's a number of policies that it fired off from labeling to encryption all the way down to versioning here, and all that happened under the developer. So the value prop here is that the developers can have native access into GCP. And they could have done this through the console, through Terraform, or an SDK or the shell console, however they felt that they needed to do a deployment or an update or change. Turbot's going to react to all the stack-driver events that are happening in the background, and then it's going to take action like you just saw. So all this is happening in real time, the CMDB is completely updated in real-time so all those configurations about the bucket and everything that happened is updated. It's completely searchable. So if I were to search for this Bob Demo GCP bucket, it's already there in the CMDB and searchable, all the metadata here can be searched across in the CMDB as well, the activity that I showcased, also the controls that are set. So I can not only see the storage controls that I had set in the environment across my bucket - in this example I have controls around versioning and labels and encryption at rest - but I also have those CIS controls overlayed so I can see how well I'm performing against not only my company policies but also enterprise best practices like CIS.
[00:07:12] Now here I'm just looking at my Bob Demo GCP bucket, but if I went up the hierarchy to all the storage buckets in US region or all the resources within bob-demo-project, now I'm looking at a higher level of controls across different resources, like compute engine and network and kubernetes etc. But here I can then start analyzing, well what is my biggest area of concern? I could sort by alerts, I could see across my Google project here that my CIS overlays of controls are the biggest issue, I can drill in there. I can see all of my CIS controls that I have set so I can see each seciton of the CIS report, I can drill in even further on that report and get to individual sections and look at - in this example - I can look at section 402 on block project-wide SSH keys on virtual machines. And I could see each virtual machine within this one project and I could see what's being adhered to. But I can keep going up the hierarchy to look at a broader visualization of all my projects across my organization.
[00:08:31] And so, here for example I have an instance here that is adhering to SSH-wide keys which showcases how a change in Turbot will also update the CIS report in real time. And so here I'll just go to the compute engine. We'll load up that screen. There we go.
[00:09:14] So I have this GCP virtual machine instance, so Bob Demo GCP Instance 3-23. Just another resource managed by Turbot in the CMDB. In this use case I'm going to make a minor change by adjusting the SSH-wide keys and so here I will edit, unblock the SSH keys, save. Alright and we'll wait until that officially saves there and then we'll view this in Turbot. So we'll go back here and look to see how the instance was updated, So we can go right to the instance itself and we can look at the history of what had happened here. We can see here that Bob updated and removed the block SSH keys so I can see the actual diff history of what Bob had done, and the cause of that had updated not only is our Turbot policy into an alarm state now, but also our alarm for CIS control section 402. And then Turbot comes in and it will - because it's in enforce mode - it then will actually reset the configuration which will then update again and I can see the diff history that it added back the block SSH keys and now everything has turned green. And so Turbot not only is showcasing your alarms against your policies that you set, but also against the CIS controls, and that's all automated in real time and visualized within the live dashboards that we have or down to the very specific details you can get to in the controls here.
[00:11:28] Now, how to set policies within Turbot. If we just go back to that bucket that we were working with earlier, I'll showcase some of the policies that we had set there to talk through some of those examples in a little more detail. As an example, just going back to this particular storage bucket, I could see all of the policies that I have set against that bucket. So the CIS controls, I have set 501, 503, 502 is set to skip in this example, but I have these turned on, I have labeling being enforced which we saw quickly, I have some other controls in here, so my active controls are around the active age of those buckets and how long they can live for, to whether it's approved or not, naming conventions, is it in the right region, if it's not you can automatically delete it or alarm. You can automatically enforce encryption versioning, etc. And so, number of different examples here that I have set.
[00:12:43] But just to talk through how to set a policy. In Turbot, it's literally point-and-click. So if you wanted to set one of our 6000+ pre-canned policies, as a simple setting you can set things to Skip, meaning that maybe you don't care about bucket versioning on this particular bucket, or some other layer of the hierarchy that you can set whether across the region or across the project, or grouping of projects, across your folders. You can set it to Check, so you might say I don't want Turbot to Enforce and I don't want it to Skip, I just want it to alarm and know whether or not the storage bucket has versioning enabled or disabled. Or you can set it to Enforce. So what you saw earlier was that Turbot enforced versioning on the bucket, so it handled that immediately across. When you set policies you can also set the precedence for the policies so you can set whether it's required or recommended. When a policy is required, it's mandated against all of the descendent resources so when you set a policy it will automatically inherit down your hierarchy so if you set a policy at project level, it will automatically - in this case - inherit all the way to your buckets in every region. And you can require that that setting is in place, and the only way to change that policy is to reset that policy or to make an exception to the rule. And so if I wanted to make an exception on this particular bucket, it's the same way that I'm setting the policy here and I can make a change. So the cloud team can come in and make an exception to the rule that's required.
[00:14:16] But there might be circumstances where you might want to delegate authority down to your application team. So as a cloud team you might recommend a default, so versioning is not - in this example - versioning is not a top priority policy that you set and maybe it's more of a guidance or recommendation, you can set that versioning should be enforced to be enabled, but it's just a recommendation, and then you can delegate authority down to your application teams to toggle that on or off as they see fit. You can annotate why you're setting the policy, so you can write some comments or documentation, you can relate it to control policies. You can also expire those policies as well - So you can never expire the policy settings so it'll always be enforced, or you can set it to one of the pre-canned durations, or some custom period of time. Then you can go create it or set the policy.
[00:15:03] So in this example on this particular bucket we've created together, it's actually inheriting the policy all the way from the Sales organization, and so I have this complete hierarchy here where I have Turbot as the global level - there's no policies set there - but within the Sales folder part of the organization, that's a policy that's set and it's inheriting all the way down to my other folder called Bob's Demo Account to my project called bob-demo-project down my multi-region in the US project, down to this bucket. So that inheritance is happening automatically, so I can just set policies once, and have them inherit for any new or changed resources in the environment.
[00:15:56] Now as another example, so we had looked at the simple way to set policies, Skip, Check, Enforce. But there may be use cases where you have nuances or conditions around those pre-canned policies that you want to set. And so that's what we call calculated mode or Calculated Policies. So with Calculated Policies you can set a query that goes against your bucket that then renders with a template that is going to raffer your pre-canned policies that you have, so that you can set conditional logic such as if the bucket has a certain name or if it has a certain tag or a certain configuration, then do X. So in the use case that we had together, my bucket didn't meet these conditions. So the conditions were: if the bucket was named bobdemotemp or started with it as a prefix, or if the tags had test=temp in them, then disable versioning. But because it didn't meet those conditions, it actually enforced versioning, and that's why that value got inherited.
[00:17:09] Now with calculated policies you can do live testing of these templates. As an example in this use case I could pick my demo bucket as an example. This is a graphQL query that is simply pulling the bucket name as well as the tags that Turbot had generated. And so here, these are the tags it had enforced on the bucket earlier, such as the company name, that Bob created it at what time, etc. All this is the metadata on this bucket and that's rendering against this template here, so I could see what the result would be. So this particular bucket here in this example, would actually enforce: enable. But if I were to change it to make it so it doesn't meet the condition like if it started with bob-demo which this bucket does, that just does a live use case so I can test my template, test my query in real time. So it's a nice testing tool to test your calculated policies so that you can then set different conditions in your environment.
[00:18:13] So what I'm actually going to do is actually just show this to you live. So if I added the key value pair test == “temp†then it should disable versioning in real time. And so what I'll do is I'll go back to my project here, I'll go to my storage browser, go to my bucket here, go to labels. So these were the labels that go enforced automatically earlier just like you saw in the Turbot metadata. So if I added the label test == “temp†and hit save. Then let me refresh the Turbot console.
[00:19:22] Great. So Turbot here on my bob-demo-gcp bucket there's me here, updating that storage bucket, adding the key value pair of test == “tempâ€, and what happened once that configuration was set, Turbot then re-calculated the policy, it used to be Enforce: Enabled now it's Enforce: Disabled. And because that's the new policy, calculated, now I'm in alarm state, so my bucket's no longer meeting policy because it has the test temp tag or label. Now it's not meeting that condition anymore, where now the bucket should have disabled versioning and so it goes into alarm, it disables versioning, I can see the CMDB update and now everything's ok. And so what Turbot has done behind the scenes is now updated versioning to no longer be enabled: true.
And so all that happens in real time which you saw, once changes are happening, Turbot is recalculating the reasoning of those policies and automatically making updates in the environment.
[00:20:32] Now, we just reviewed how to set a simple policy, a calculated policy, and we also have the concept of Terraform stacks. So a Terraform stacks is another way to set a policy. This is different than what I mentioned earlier - I mentioned earlier that you can manage Turbot with Terraform - that's how you can configure Turbot with Terraform. But we also have another feature where you can set Terraform stacks as policies that automatically get enforced across your projects. So I'll just simply show you what that policy looks like. What I'll do here is I'll go up to my projects, I'll filter on Policy Type, go to GCP, go to Project, go to my Stack.
[00:21:33] So in this example I have a policy. So instead of it saying Skip, Check, or Enforce, my policy setting is my Terraform HCL. So in this example I'm setting a Terraform - this is Terraform out of the box, nothing special here from a Turbot perspective - here it's simply creating a pubsub_topic and a subscription with some configurations and then what it's going to do is deploy that across the environment. So this is an example where you can have a stack managed by Turbot as policy, we can basically run the plan and apply, and it continuously enforces that configuration, so if any changes occur, Turbot will then manage the state and automatically set it back. When you leverage that within the product you also take advantage of all the activity and the diff history so as those policy settings are changing, you can also see that. So earlier I made a change to the policy and I can see the diff history of my Terraform HCL code within the project. I can also see how I make changes and how Turbot will then reset back the configuration.
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!