Disclaimer: Automated Transcript
Hi, to start off, Turbot is 100 percent API-driven, we're a graphQL backend, so any actions or any query or information that you're going to see in this graphical interface or this console you can do from an API perspective. We have a Turbot CLI that you can leverage for higher level commands. We are also a provider for terraform, so you can manage Turbot at scale, using Terraform as well.
[00:00:28] So the console here-users can interface with Turbot through a console or gooey layer that you can have multiple directories that are associated to Turbot. So here I'm going to log in with my Google off credentials, my Turbot.com credentials. But you can integrate your Amazon SSO, your Azure AD, ADFS, Okta, Ping Identity, any LDAP, any SAML-based directory or multiples of them to the product and users can authenticate in. So I'm going to log in with my personal credentials here. I already did MFA this morning, so I'm now just re-authenticating back in. But any multi factor authentication would occur through your directory provider that you've integrated with. When you're authenticated as yourself, you land into a profile page and you could see your audit activity as these are all the actions that I've taken. Some of them were in Amazon and others, if I go back, some things were in GCP, Azure. And so in this personal audit trail, I could see my personal activities and drill into the information. I can also see my favorited sections of my hierarchy and then I can drill in and get into the product itself.
[00:01:44] But before I move forward with anything in Turbot, I'll just showcase how Turbot is an interface that administrators can use to manage policies and identities. They can discover and search across their entire configurations, across multi-cloud for developers or application teams. They might be using the product to also do the same thing, so they might be delegated authority to manage policies and identities or at minimum they can see what their policies and identities are in their applications and see all the configuration changes and drift and audit trail. But you don't have to use Turbot as an inline tool. You don't have to use us for authentication. Your developers don't even have to know that Turbot exists, it could just be a tool for the cloud team. So it depends on how you want to deploy and roll out her bot. But just to show that we're working behind the scenes. I'm going to just demo just quickly get into like an Amazon account as an example, spin up an S3 bucket, show you how Turbot reacts to some of the configuration changes in the environment.
[00:02:46] So as I get into my Amazon account, this is an example where you could use Turbot to assume roles in your Amazon environments, so you could use us to log in as either roles that serve out the finds in our own role-based access controls. You can use our roles and modify them for your preference, or you can bring in your own roles and then use that in Turbot to handle your assumed role model. And we also do a user-based model with associated roles. There's a number of different authentication measures we can do in Amazon or you just don't use us at all for those type of features. In Azure and Google, users would just login directly to your portals or to your console, but this is just an extension feature that we have for Amazon.
[00:03:37] So when I log in as a super user, I now federated into my Amazon account with Bob@turbot.com, assuming the super user role. Here, I'm just a developer in this example, I have immediate access into Amazon. I could be interacting with Amazon through the CLI, through terraform, CloudFormation, any SDK. It doesn't matter how you deploy or how you make changes in your cloud provider, Turbot's reacting towards events. So as changes are occurring, that's what Turbot's reacting towards. And so in this example, as Bob created a S3 bucket, and he created in the right region - maybe US-East is allowed in this example - the developer had self-service to create the bucket. But as a cloud team or as an enterprise or an organization, you might allow yourself service to your developers, but you can't trust that they either know or care what type of configurations need to be insured. And so whether it may be versioning or encryption or certain tagging policies should be in place, you can't expect the developer to actually know all those configuration details and always get it right at all times. And this is the value of Turbot, where you can marry the agility for the developer to just do things themselves, like spin up a bucket, make changes, but Turbot is going to come in and ensure control in real time.
[00:05:10] So if I just refresh the page-Turbot picked up that the bucket exists, it captured in the CMDB, it automatically then enabled versioning, it automatically then ensured encryption at rest with AS256. It also tagged the environment, so it automatically tagged it with key value pairs in this example. It's a simple example. Just automatically tag it with the company key. But the value is Bob Bagels - and that's a static key value pair. Whereas others were handled through inheritance - this bucket pulled in a higher level metadata from a folder structure and brought down that this is part of the sales organization. It also marks some things noncompliant because they weren't set correctly or it automatically tagged it with the bucket name. And this is showcasing how the policies can interact with the CMDB behind the scenes and pull in context. So understanding the bucket name can only happen after the bucket is created. This is the example where we brought in the bucket name into the tagging. It also did some interesting things like tagged it with who created the bucket at what time. It derived static static prefixed with a dynamic value for the cost center. And so we did some interesting things behind the scenes and I'll showcase what that looks like from a policy standpoint. But just to show it's not just on creation of resources, it's also around updates.
[00:06:44] And so if I updated this, you know, simple company Bob's Bagels to Dave's Pizza Shop and saved it, as a superuser those types of changes are allowed. But Turbot's not going to like that because the policy is to enforce that Bob's Bagels is the actual value for that key that's accepted. And so if I just give it a second, refresh the page here.. Turbot already picked up that Dave's Pizza wasn't accepted and automatically then changed it back to Bob's Bagels. Turbot's doing more complex things behind the scenes. It's setting the public access block per your configurations. It's also doing bucket policy statements like to ensure encryption in transit or explicitly deny certain encryption keys that aren't approved. There's more advanced use cases around what your policy statements are, if they're allowed or rejected, or if you have principles that are allowing for anonymous access to be locked back down the certain accounts or service providers or identity providers. And so there's a number of controls that you can set. These are just a few examples of simple ones.
[00:07:57] All that gets reported back into Turbot. And so you can see your accounts, your user activity - I just refreshed the page here - so I could see that Bob created the bucket, and then there's some updates since then. And so I can drill in and get straight to that bucket right away. I could have searched for that bucket if I was already in the console, I would see some activities pop up. But right now, I just jumped into a dashboard of this Bob demo 1-15-2025 bucket, and that's part of a hierarchy. So this bucket lives in US Region 1 one in this Amazon account, in this folder structure called Bob's Demo in the sales organization as part of this overarching turbine implementation. The CMDB entry for that particular bucket is here. This is my Amazon configuration married with some Turbot configuration detail. I could see all the activity information about that bucket. So at its simplest form, all this activity just in my last update. So Bob updated that bucket. This is when Bob moved it from Bob's Bagels to Dave's Pizza that then trigger Turbot to alarm that the tags weren't set correctly and then Turbot updated the tags. And then the CMDB entry was re-updated back from Dave to Bob and now everything's marked OK.
[00:09:23] And so in a quick showcase of the workflow, this is how Turbot operates just in real time. So we capture an event of a change. We then will alarm if that changes inappropriate for your policies. We'll then take some type of action. Right. So if you have us enforced tagging, we'll then take that action, then force and then the CMDB will be updated in real time as those changes are occurring. And then Turbot's verifying that everything's OK. And so we do a complete closed loop on that from any type of change or event in the environment, Turbot's reacting to then ensure that you're always meeting company policy or company controls. But if I just look at the entire history of that bucket, there are tens of events that fired off just on that creation. And so when Bob created that bucket, a number of activities happen, from Turbot calculating the reasoning for why the policy should be put in place, it could be that the buckets named a certain way or it has the certain configuration, or that if the creator of it was a certain person or coming from a certain group might dictate a different policy. And so Turbot does all that calculated reasoning behind the scenes to then detail out what the policies are going to be and then it takes that programmatic action and start alarming or saying some things are approved or taking action to correct, like you saw. And so Turbot's much broader of a platform to handle all that into an alarm state so that you're always adhering to those controls. You could see your complete audit trail of changes that are happening in your cloud environment also in Turbot. We put that all together in a relationship. So you can see your resources tied to their controls, tied to the activity, tied to the policies that are set and the permission model against them.
[00:11:10] And so I'm looking at the controls here and my adherence to all the different policies that I have set. And this view might not be that worthwhile. So I'm just looking at one bucket and it's just showing that all my controls are being adhered to. But if I went up the breadcrumbs and just went up to Bob's demo account, well, now I'm looking at a broader scope of my controls. At this level, not just work looking at one S3 bucket, I'm looking at many S3 buckets plus a bunch of other components within Amazon and Azure and Google, kubernetes, Linux, etc. If I want to drill back down into that Amazon account and then maybe just filter on that S3 again, and then just look at my buckets - Here I'm looking at that control that was looking at before in one bucket - and now I'm looking at all the buckets in the control adherence to that in my Bob's demo account.
[00:12:04] But there's different context that you can take. I could say, well, show me all of my controls in Amazon or show me those controls across Amazon, across the CIS report. And so I'm still filtered on Bob's demo account, I'm looking at the Amazon CIS Version 1 report across the four sections of the report. And if I want to drill into more details, I can then start looking at the subsections and the adherence to that from the drill into an example, one of Section 107 that is around ensuring that your password policy has at least one symbol and you my adherence down to something as nuanced as an account password policy that's also captured in our CMDB. But if I didn't just look at one and wanted to look at every all of the account password policies in the here and the section 107, that's just me re-filtering.So instead of looking at my by Bob's demo account, I'm looking at the entire sales organization in this environment and looking at all of their account password policies. And so that same S3 example that I had just given, that's true for even obscure resources like an IAM account password policy. So if I come in here at IAM, go to my account settings, try to change my password policy - I'm here as a super user, so I have rights to alter these type of configurations - if I was to remove the requirement for a symbol and my password policy and see that will turn, it's going to pick that change up just like the bucket changes. Any configuration change it's going to pick up. So at that point, that it's going to react based on the policies that you set. And sometimes those policies might relate to your own internal controls or they might relate to things like your CIS Benchmarks. So you could see here now it's already in alarm state and then it's going to come back in and close that alarm because I have enforcements turned on. But I can just look at that CMDB entry of that account password policy - So this CMDB entry is this right here - we're capturing all those configurations and then the same thing with the audit trail. So I could see Bob updated move requiring symbols from true to false, Turbot alarmed that my password policy settings weren't configured correctly per my company policies, but it also alarm that I'm also not meeting Section 107 of the CIS report. And because I have enforcements on Turbot then took the action to update the password policies, basically moved it from back from false to true and then now everything's in a green state.
[00:14:40] But this all happening in seconds behind the scenes. And so you think of developers having self-service - they can simply move forward with the changes that they're making safely. So even if there are mistakes in the environment, which, of course, that will be, Turbot's going to come back and always ensure that those mistakes are corrected instantly. You as a cloud team don't have to do any manual follow up, these tickets aren't problems in the environment. They're handled programmatically by turn, but all reported with full audit trail. But you do not need to be in the middle and your developers can be elevated to stay focused on their application team tier.
[00:15:19] Now, the other type of examples could be around security groups and you could see your adherence to your CIS controls for networking and in how you're adhering to that - a very similar demo, very similar concepts of an updated security group - and show how Turbot can then alter and change that in the CIS report to be updated in real time based on those changes, and those corrections would occur.
[00:15:46] What I'll do is I'll shift towards showing how to manage policies in Turbot and there's a few different approaches that you can take, and then we'll stop there for some questions. So I'm going to go back to that bucket that we created together, so that's just live GraphQL searches across the CMDB. So now I'm looking at this particular S-3 bucket that we created together. If I jump over to the policies of that bucket, I can see all the policies that are inheriting onto that bucket. So I have some things around the active age of that bucket. How long can it live for? From a time lived. But maybe last used, last accessed or is the bucket approved because it's in the right regions or not? Or it doesn't have the right conditions like a certain naming convention or configuration details? The public access block and ensuring that it's meeting those type of standards set by the organization. Make sure it's not publicly exposed to encryption at rest in transit. A number of different examples here, the tagging that we went through in more detail. But if I just pick one of them, say bucket versioning. Well, for bucket versioning, the policies are very straightforward to set. So our pre-canned policies, which we have over 5000 pre-canned policies in the platform across Amazon, Azure, Google, Windows, Linux, kubernetes, etc, they're pre-canned to simple point and click decisions. So in this example, it's saying for bucket versioning, do you want to skip bucket versioning? Do you want to just alarm if things are enabled or disabled for versioning or suspended, enabled or do you want to enforce it? And so in the demo example, you saw that versioning was enforced across the buckets. And so it's as simple as that type of selection and this particular policy is actually set at a higher level. So the default is set to skip the global Turbot Tier tier, there's nopolicy set, but in the sales organization, I actually have this policy set and it's inheriting down to the bucket I just created. So it's inheriting down to my demo account folder, my Amazon account within the ES-East-1 region down to this bucket. So this inheritance is happening in real time. The policy was set above. And so when I created the bucket, the bucket relates in that organizational structure and that's why I got that policy to enforce versioning. So policies can be as simple as the skip, check, enforce or like a radio button or maybe it's a boolean enable/disable.
[00:18:43] There's also more advanced ways to set policies. We have a calculated policy mode that you can set. So you can create conditions based on the pre-canned logic. So if there's specific nuances that you want to set to say, well, versioning is not always enabled, even within my sales organization, maybe versioning is only enabled if the bucket has a certain name or it has a certain tag enabled on it.
[00:19:10] And so if I just picked a bucket here to test with. We have a testing framework. So here I can select the test testable resource. I can run a GraphQL query. So this is just pulling the name and the tags. And so here it's just showing at this example bucket, this query, this is the type of metadata information I'm working with. And then here I lay in a template, which would then put the conditions wrapped around those pre-canned policies. So in this example, it's saying: if the bucket name is Bob Demo Temp, then disable versioning or suspend it. Or if the bucket has the tags “Test equals temp” key value pair “test temp”, then disable it. But if it doesn't meet those conditions, then enable. So this is an example where the bucket I created earlier didn't have those conditions, that's why it actually enforced versioning. But this is a real life test case. So as you're building these policies, which we're happy to support, you want or you could build yourself and use our testing capabilities, it's real time testing. So if I changed that logic there, it shows how the difference in the policy.
[00:20:24] But once you set your policy, whether it's in this advanced mode or just simply skip, check enforce, we give you precedence requirements that you can set. So you could say, I require that this is mandated across all of my resources. You can also just say this is recommended where it's a default value, which then delegates authority down to your app teams to toggle it. So you can require policies that can only change with exceptions to the rule. You can also recommend policies that set a default and then others downstream can toggle it. It's very flexible to set that. You can annotate (explain why you're setting a policy), you can also expire the policy and whether this is an exception or this is a policy that's set, you can expire those decisions for pre-canned timeframes or some custom period of time. But that gives you the full ability to set those policies across. And just to show you a calculated policy work in real time - If I went back to S3, and I went to that bucket that we created together and added that tag - So the condition on our calculated policy was to say, you know, disable versioning if it has a tie called “test temp”. Okay, I saved it. Well, Turbot's going to pick up that change. So here it just picked up that Bob added the key value pair “test temp”. And then you could see the policy change now to enforce, disable or suspension of a versioning and then say, well now, you're not meeting policy anymore because the policy is that if it meets this condition, you shouldn't have versioning set. And then it just suspended versioning, it just updated the bucket back to able to suspended. And now we're OK for this very particular bucket with this condition.
[00:22:38] There's other advanced ways to set policies where just the pre-canned, which I showed you, the calculated policies, but another type of policy that you can set are Terraform stacks that you can deploy through Turbot. And so to show you that what I'll do is I'll get to a Terraform stack. So here I have a Terraform stack that's running as a policy within the environment. And so here I'm enforcing the stack to be configured and the policy for what that's enforcing is actually just my Terraform HCL code. And so instead of saying you've skip, check enforce for versioning or encryption or whatever it might be, the policy setting here is actually just Terraform. And so in this example, I can use Turbot to automatically not only deploy my Terraform stacks across whatever scope in this example, across the sales organization, in all the Amazon accounts associated there. But it also will always ensure that that stack is being configured. So if I were to change the logic here and say, you know, monitoring role 58 is no longer approved, and I'm muffing some type of configuration in it. So in this example, I have an Amazon IAM that's also an I am minoring policy that I'm being created with some custom IAM conditions and then I'm attaching that role and policy together. And so if I was to run this new stack across the environment that policy is now inheriting to all of those Amazon accounts underneath, include including my Bob demo account. And so now that's the new policy, so now Turbot's going to go out and reconfigure your stack and then it's also going to always ensure - so someone tries to mess with that stack outside of this pipeline - Turbot going to reinforce it. So therefore, Turbot is actually managing state in our CMDB. So you'll have to manage local state or remote state, the CMDB is updated in real time, so that could actually be your state file and context for Turbot to always ensure your stock is being adhered to.
[00:24:57] You can visualize any of our controls running in real time. And so if I was just to view the log, I could see that Turbot is actually launching a container right now to actually isolate that Terraform run into its own container and then it's going to execute it across the environment. So this takes tens of seconds to run and we'll see it kickoff shortly. But I'll go into the IAM account or the IAM service, I'll go to Roles, And you could see that my monitoring Role 58 is already created and Role 57 is deleted. So Role 58 is now in this environment with the attached monitoring policy that was associated in stack. Now, if I was to come in as the super user and accidentally or intentionally remove that policy attachment, I have those type of rights in this environment so I wasn't prevented. But Turbot is going to react just like you saw on the S3 tagging or that IAM password policy, it's going to react and say no, this is not part of your configuration. It's going to re-attach the policy because that's what your Terraform had stated. All this is reported back in the Turbot - just do a refresh on the activity - so you could see all the changes that I just had made. When I actually changed that policy there from moving it from 57 to 58, that's all captured in our audit trail. So even your Terraform HCL and your policy statements, those were captured as changes just like an S3 bucket is being updated. What is being created and destroyed is all captured there - all the other accounts that also got that role deployed to it - I can actually see what was created and what was destroyed. I could see the full plan and apply process logs as well with it. Now, if I just come back here and refresh the page. The monitoring policy is now reattached from our Terraform control.