Subscribe
Share
Share
Embed
David Boeke is the CTO and VP of Services at Turbot, a cloud governance platform that automates compliance, security, and operational controls for the public cloud. Prior to joining Turbot, David served as the global head of healthcare technology and the global director of architecture and integration at Janssen, a Johnson & Johnson subsidiary. Before those roles, he worked at Johnson & Johnson for 17 years, rising to the senior director of enterprise architecture during that time.
Join Corey and David as they discuss what exactly it is that Turbot does; how the cloud makes it easier to keep track of all of your assets thanks to its searchable nature; how David’s background in pharma helped him bring a regulation-first mindset to the cloud; how large organizations sponsor conferences like re:Invent to attract talent; how Turbot works with one-person IT shops all the way up to enterprise with two dozen developers; why tagging resources is important even though it’s one of the least sexy things you can do; why teams should focus on one thing at a time, automate that thing, and move on to the next thing; how Turbot reimagined its dashboard reporting design to give users more peace of mind; and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by David Boeke, CTO, and VP of services for Turbot. David, welcome to the show.
David: Hey, Corey, great to be here. Thanks for having me.
Corey: Of course. So, this is a promoted episode as I tend to do from time to time and as a result, we are talking about Turbot, as opposed to the other approach of, “So, where'd you grow up?” And, “What do you do for school?” Let's talk about the company. Turbot’s interesting to me because it targets an area that is very near and dear to my heart, specifically helping organize cloud resources in a way that you can understand them. But it does way more. What do you folks do?
David: We believe that we're really the first true governance platform. There are a lot of tools out there, there's a lot of things that will audit what you're doing, and give you reporting on kind of what you're not doing well, but we really designed Turbot from the ground up—as a governance platform—as tooling for people who like to build things in the Cloud. And one of the things I always like to tell customers is, if you love cloud-native, you're going to love Turbot because we're kind of multi-cloud-native. We're a single platform that you install, and run, and can discover resources across all of your clouds, and then we have a ton of built-in automations within the tool that help you do interesting things with that data. And once you have a complete CMDB and change history of all of your cloud resources, that's updated in real-time.
The idea of then writing automations against that data and understanding it better, maybe for the purposes of security, maybe for the purposes of finding where there's cost and waste, maybe it's something simple, like tagging resources. There's so much that you can do in that space once you have the data. And that's really what we excel at.
Corey: One of the problems I've always had with the idea of building a tool or getting any tool that purports to solve these problems, is it's not a tool. It, more or less, is a few hundred or thousands of tools. So, when I was digging into Turbot, it’s, oh, you actually have 6000, I think was the number that your marketing pages quote, number of things that can be adjusted or monitored inside of a given cloud environment. Am I roughly accurate with that?
David: Yeah, so there's a, I think, roughly right now about 6000 policies where we're adding a few hundred every week. So, a lot of those based on customer requests, some things that we see, a lot of it driven by the actual acceleration of the Cloud. So, you've got to Amazon, you've got Azure, GCP, all pushing new things, new services, new capabilities for existing services on a daily basis now, so it takes a lot to keep up with that. And then think about that in terms of an enterprise mindset, and how might an enterprise want to use that service, or do something with that service?
Corey: One thing that I find compelling about tooling that solves for this is first, it's not something that's exciting. I've got to be blunt with you. It's just not to most people. I get excited about it. When I talk to people, they look at me like I've skipped a circuit somewhere. The idea of governance and seeing what's going on across your estate is not resonant with people who are building these small apps, and they're just setting out for their first time in the Cloud.
You generally only appreciate the value of this, either after having done it a few times or in the more common case, you are an enterprise who has compliance obligations placed upon you, where understanding what is in the environment is of critical importance. And I've got to be honest, humans suck at this. It's something that you need tooling to solve for you. It's neat to see that there's a vendor out there, in your case, who at least seems to understand aspects of this. Rather than, oh, we built the same dashboard everyone else is, but we're going to compete on better customer service, for example.
David: Right. No, that's totally true. I have led large enterprise IT organizations in the past. One of the things that always stuck in my craw, because early in my career, I went from being the business unit IT guy, where I was building solutions, or purchasing solutions, and deploying them, and configuring them for customer need. And then at some point in my career, I decided that these guys at corporate don't know what they're doing, and they're preventing me from doing what I want to do all the time.
So, I'm going to go up to corporate and I'm going to fix those things. So, I shifted my career and moved into the corporate environment, and then I became like the Borg and started preventing people from doing the things that they want to do because in a large organization, you have a million people spending hundreds of millions of dollars all doing the same thing in different ways. So, I've seen the problem from both sides on the enterprise IT side. One of the things that always stuck with me, and I think very early on when we were originally looking to move to AWS as a platform for large enterprise applications, was we would spend literally hundreds of millions of dollars a year on new IT capabilities, whether that's in the data center deploying disk, deploying virtualized compute, networking equipment, etcetera and—as well—apps, and as soon as you deploy them and put them in place, you would lose them forever. No one could ever find that asset again if it killed them. And then you'd spend hundreds of millions of dollars more implementing something like ServiceNow, so you could put human processes around tracking all those assets and what changed on them, etcetera and the thing that jumped out at me very early on—and really who brought it to my attention is our CEO, Nathan Wallace who used to work with me in that enterprise environment—was that with the Cloud, you have an accessible, you can search and find those resources. It's a programmable environment, and you now have this ability to discover things, but also query your existing environment and see what you have. You don't have to lose those assets anymore. And so, one of the things I'm really proud about Turbot is that we do that discovery, we monitor all the real-time events. I have a customer who has 1000 AWS accounts. And if you imagine the Kinesis Stream of event flow from 1000 AWS accounts of all the changes happening across all those accounts.
Corey: Oh, yeah, it takes your entire microservices architecture and makes it worse.
David: [laughs].
Corey: And let’s not kid ourselves, a lot of AWS services, have trouble even communicating with instances of themselves in other regions, let alone different accounts.
David: Yeah. No, totally. And the idea of now, okay, I have 1000 different accounts, and I have a dashboard that I can go in and I can search for an instance ID. I can search for a bucket name, and instantly find out what that is; Who deployed it? How did it change its configuration over time? What is it currently doing? All of that information is at your fingertips.
And if I had that 15 years ago, as an enterprise IT guy, we would have felt like we were ruling the world. You know, you always go back to your 15-year-old self, when we were working on Apple IIs and things like that, with 16 K of RAM, and now looking at how much power you have on your phone: it's kind of the same thing, which is that this migration to cloud and moving all your workloads there, gives you this real visibility to what you're doing, and how you're spending, and what are your assets that are deployed in the environment. So, I really love that aspect of it.
Corey: One thing that resonates with what you folks do is that it's separated from the typical case in this arena, which I have an unfortunate amount of personal experience with. Hi, we're a new startup and we're going to tell your bank how to properly run your IT department. It's condescending, it sounds like a bunch of people who have no experience in this space who are basically storming in to tell companies they're doing it wrong, and here's what they should do instead, without any conception of what life in that environment is like. And what makes you folks interesting is yeah, if you squint hard enough, you look like that. You're you've been around six years, you're definitely a startup. But the people who started your company have come out of that world. You were at Johnson & Johnson for years yourself, for example.
David: Yeah, and all of our core team, both engineering and on the management side, all came out of large IT, either in the financial industry or in pharmaceuticals and the life sciences industry. And those are two very highly regulated industries that spent a lot of time early thinking about these problems of if you move to the Cloud, how do you do that in a regulated environment? And so, there was actually a ton of really great people out there that were frustrated because their day job was essentially doing PowerPoint presentations to people that really didn't understand what they were talking about. And we have, over time, come out ourselves and said, “Hey, look, we want to do something different. We want to take this experience that we have in doing these large scale cloud transformations, and move that into tooling that we can then accelerate other organizations.” By ourselves, we can only ever make an impact to one organization at the time, but collectively as a team, and building a product, we can have that same impact across, hopefully, hundreds if not thousands of other organizations that are going through that same pain.
Corey: That's partly I think, where a lot of folks get it wrong. The things that work for Netflix, quote, unquote, where they get on stage and talk about these amazing transformative things that they've built. There are a few problems there. One, you folks stream movies, let's not kid ourselves. Two, you have enormous amounts of resources that, to be very blunt, most traditional corporate IT departments do not have, full stop. So, trying to retrofit solutions that work in a radically different culture, into an environment where you don't have the same freedom and you have serious regulatory burdens that may not exist elsewhere, mean that a lot of the first attempts at things like this come across is, to be honest, kind of a sad joke.
David: They do. And I really feel for—you know, a lot of people that are in those situations understand the trade-offs understand a lot of the technical approach that needs to be taken in order to solve these problems. But unfortunately, because their management chain is focused on a different business—they're not focused on a technology business—it's difficult to raise those things in a way that can get you the resources that you need to do it effectively. So, many of our customers are working in a resource-constrained environment, where they have a few internal people that really understand it and get it, but there's no way that over time, they could actually hire and maintain and keep the talent that would be necessary in order to build the tooling that they need.
One of the things that was really intriguing to me—because I've been at re:Invent almost every year since it’s initial inception—is that Capital One—you know, large financial institution—has been a platinum sponsor of re:Invent for a number of years, mainly because they were looking for people to bring into their organization. It's essentially a recruiting mechanism to go find people who love this stuff and that they can bring in because, as a company, even a huge financial institution, a huge life sciences institution like Johnson & Johnson, it's hard to find and attract technical talent that wants to come to a large IT organization, a traditional IT organization, and do this type of work. And I believe that's changing. I do believe that the years and years that a lot of IT departments have spent outsourcing more and more technical work, that is coming full circle. The ability to move workloads to cloud and cloud transformation, along with the transformation of data science and companies seeing the value in technology again, means that IT departments are going to be re-funded business leaders are hearing it from the Mackenzies of the world, etcetera, that they need to reinvest in these areas and build out the technical expertise that they have.
And so, I think there's going to be an opportunity, and over time, we'll see larger internal IT teams going. But I work with customers that have one guy who gets it, and he has no ability to hire any other resources to help him with this problem. And he needs automation and tooling that's already done, so he can roll that out and achieve value. And then we also work with enterprises that have two dozen software developers who write their own guard rails and their own controls on top of Turbot, and deploy those, and manage large fleets of AWS accounts and Azure subscriptions and Google projects. So, it's really a mixed bag right now, but I see more people moving in that direction, especially those that are getting large return from their cloud investments and going more cloud-native in their workload migrations.
Corey: One thing that is a universal truth—and I don't care how big your company is, or small—is when you look at how things are set up from a governance perspective, from a tagging perspective—which is my personal hobbyhorse—it's always the same answer, which is: you haven't been doing it properly, and there's a giant gap between where you should be and where you are today. And I don't know that that gap ever gets closed, but you can always do better than you are. But it leads down the path of the first thing people do when they see these things is feel bad. I hate that model because first, it's not your fault. There's a lot of things that go into this. And secondly, you're never going to get to 100 percent. But automated systems are the only way forward. Telling humans to tag things the right way all the time does not work because we're humans, we suck at doing the same thing over and over repeatedly and consistently. So, how do you approach that? How does that inform how you go to market?
David: Yeah, I love that analogy because it is a microcosm of, kind of, what happens in a real environment, which is that some smart people get in a room early on and say, “Okay, we need to have tagging standards.” And you come out with the tablets of the eight tags that every resource must be tagged with, and you kind of go down that path. And the first thing you do is you just you publish that. You write it up, you send it to everybody, you say, “Okay, by—whatever it is—July 1, all project teams must have all the resources tagged, and we're going to go forward.”
And of course, it doesn't happen. And you do some reporting on that. You pull out data, and then you're frustrated. Like you were saying, you feel bad. The management feels bad that hey, we spent some time, we decided on this, we came to consensus across the organization, we rolled it out, we communicated it, and no one did anything. And no one did anything, not because they don't want to, or whatever. Everyone's got a full stack of work on their plate, and they're keeping their applications running etcetera, and running around and tagging things are probably the least sexy thing to do in that space.
The next phase of that, that I normally see, then people go down the road of, “Okay, well if we can't get people to do this stuff manually, let's automate that tagging process.” And then that sends you down a software development path. We're going to build tooling to do that we're going to build serverless lambdas that are going to run in each region in each account, and look for resources and tag them based on a central repository of metadata that we're keeping etcetera. It's a lot of work, you get all that done, you're super happy. You've got that running across all 25 Amazon regions, and you go to re:Invent, and you sit in the keynote, and then Jassy comes out and goes, “Oh, we're launching a new outpost in Los Angeles. And it has a different ARN than every other region that we have.” And it is kind of like you're constantly in this software development mindset in order to achieve any value there. And, like you said, you're still not feeling good about it.
I think one of the things that Turbot does in that space, or a few things Turbot does in that space is that the automation to tag the resources, but to discover that the resources are created, that tags have changed over time, etcetera, that's all built into the product. So, without having to do anything, just turning us on and running it, all the event model of all those events, all the resources that exist, what their current tags are, etcetera, is flowing in your system and you have a place that you can interrogate that, and report on it across many, many accounts, across subscriptions, across clouds, etcetera. So, all that's in, but I think the other thing that's interesting is the way that we approached our dashboarding, which is, we avoided the trope of the red, green, yellow stoplight. There's so many things that will just tell you, everything is wrong. You have one resource that's out there that isn't tagged and your entire environment is red. Your entire AWS environment is now a stoplight red, and everyone feels bad because of that.
One of the things that we did is we turned all of our dashboard reporting into shades of that. So, our standard view is a bar chart of how many resources are red versus how many resources are green, so you can roll up and instantly see, “Hey, 1 percent of my environment is red and 99 percent of my environment is green. And that's good. And I'm getting better over time, and reducing that.” And I think that's one thing that we can do to kind of help drive that, which is that it becomes more about how do I solve these things over time? How do I get better? How do I get less tickets this week than I had last week? I think that's our key mantra, which is, kill the ticket. Do that, and measure your performance over time.
Corey: It's the idea of continuous improvement. I think that's something that people tend to forget sometimes because you look at this monstrous amount of work. I mean, we talk about Turbot, there are 6000 some odd controls that it can wind up applying or influencing. And great, where do you even start with something like that? The idea of it is almost overwhelming and it’s, great, pick one. It doesn't almost doesn't matter which. Pick something that solves a painful problem you have now, and get started. Again, I tend not to view this through the lens of any particular tool. I've done similar things in the past with—you talked about Capital One, their cloud custodian open-source project that came out of it is, in some ways, able to do some of these things. And that wound up being a decent way to get started, too. Find something, anything, but don't just sit there and feel sorry for yourself. Fix it.
David: Yeah, absolutely. And I think that whole idea of, do one thing, and get that going, and feeling good about it, that is key to the developer mindset. It's like, you're programming something; it's 2 a.m., and you're on your fifth Diet Mountain Dew, or whatever it is, and you get that thing to run, and it passes the unit test that feels good. And you go, “Okay, what's the next? What's the next? What's the next thing?” And I think for the cloud operations team, it needs to be the same thing.
If you look at the entirety of—I have companies that come to me and say, “Hey, I want to enable NIST 853 for my environment,” which is six years of work of constant work and driving there, and you'll never reach that goal line. You need to pick up something, whether it's tagging, whether it's public access, whether it's encryption. Pick one thing; pick one control; roll that out; have that be successful. And then if that's automated, you don't have to think about that anymore. So, I can build that out, I can get all my accounts compliant with that. Occasionally, someone's going to do something off the beam, but those are going to be onesie-twosie.
But if you put that to bed, you can really feel good, and then roll in the next day and start, “Okay, now we're going to start on the next thing. We're going to look at making sure that our route tables are not being changed over time,” or whatever it is. That's the whole point there is that I love that philosophy. And I can almost tell when I work with a new customer, whether they're going to be successful or not based on that mindset. Are they coming in saying, “Hey, look, I've got a laundry list of 300 different controls in a spreadsheet that I want you guys to go implement in the next 90 days,” or am I taking an approach of, “What's the minimum viable product that we're going to deploy here? And then let's improve over time.” It's a real litmus test as to whether you're going to be successful or not.
Corey: One thing that I really appreciate about Turbot is, on the one hand, yes, you are positioning yourself as a multi-cloud offering. My argument has always been that multi-cloud as a strategy is dumb. That said, there are ways to approach it that isn’t, and you tend to offer a solution that works regardless of platform, which from your perspective is genius. One, it meets customers where they are—which is always a good thing—rather than yelling at them that they're doing it wrong. Two, the fact that you are able to service customers on different clouds absolutely broadens the appeal. And three, which is was I really what I want to dig into is, you have solved one of the big problems of building a software product aimed at the Cloud because everyone worries about AWS releasing something at re:Invent.
Andy Jassy gets on stage and, in my fantasies, he will start talking about tagging and how to do governance. In practice, I think that's not the interesting sort of stuff that gets keynote time, and then you don't have a business. But instead, it wouldn't be a feature release that causes you problems, it would have to be thousands of feature releases that most of us are growing old and are pretty much expecting are never going to happen within our lifetimes. And you're across multiple providers as well.
David: Yeah, it's interesting. I think everyone that sells tooling in this space is anxious going into re:Invent time about what's going to be announced or whatever. But it's funny, Turbot has been around for six years. So, we're a, “Startup,” I'll put in quotes, but it's a fairly long time for this space and Turbot as tooling pre-existed before AWS Organizations existed. And so, I had customers at that time telling me oh, AWS is coming out with this thing. It's called Organizations, you guys should be worried, and doing all these things.
And the bottom line is, is that the more the cloud providers deploy, you know, the more services that are created creates more things that the enterprise has to do, and that means that there's more value that we can bring to the table. Now, sometimes things that we were doing—like we had, for one of our big early controls, was the idea of finding unused resources and auto-stopping instances, things like that. So, a big thing some of our early customers were using was the ability for Turbot to, essentially for dev environments, to turn off EC2 instances at the end of the day. So, everyone goes home at six, seven o'clock, and then they basically had Turbot configured to stop those instances at the end of the day, and then start them back up around 7 a.m. before everybody got back in the office, which is a big cost savings.
It's even a cost savings over Spot, in some cases, just depending on what kind of instances you're using. Now, AWS came out with that capability and built it in the last year, or the year before. That's great. Always lean into cloud-native. We're not about abstracting you. Far from the opposite.
I think one of the key things that Turbot does is we say we never want to abstract you from using the Cloud. If you like using the AWS console, if you like using the CLI, if you like using Terraform, or Cloud Formation, or whatever the tooling is that you like to interact with your environment, we don't want to intercept. We don't want to be in the middle of that with you because that's what makes you productive, and what makes your team productive. What we really want to do is give you great tooling on the back end to evaluate those changes that are occurring in real-time, regardless of how they're doing that, and do that in a way that doesn't take away value from the developer, doesn't slow the developer down in any way.
Corey: That's part of the value, where the idea of, oh, there's now a native way to do it. Terrific. There are two problems with this. One, not everyone keeps up with every release. In fact, most people don't know that you can stop these events, and two, great; the fact that you have that as a capability also exposes ways for you to either extend it yourself or leverage it for some of the things that your tooling does, or ultimately have it replaced by that native offering, and that's great because it's not the only thing that your company does. And that's where people tend to get stuck. It’s, great, oh, you're just a thing that turns down my development environments at night. Well, that's kind of a limiting experience and offering that really helps folks out.
I do have a question about that particular use case, though. Often I'll talk to companies who really care about exactly that problem, but then analysis shows that 3 percent of their spend is development environments, and they haven't bought an RI in twelve months, so that doesn't seem to be the biggest area of concern. Secondly, there's always the outliers that seem to cut things like this to pieces, and this probably is a larger concern across the entirety of what you do. It works out super well until one day, there's a big release and people are trying to get something out the door; they're working late for a deployment or whatnot, and then the system turns off their instances. Because well, it's quitting time: go home. And it causes a disruption. How do you handle that?
David: Yeah, it was a use case that we had to worry about early on. I actually had a situation where Turbot was competing with an auto-scaling configuration. And so, the auto-scaling configuration kept launching instances, and Turbot kept terminating them because they weren't encrypted or something. But in terms of starting up instances and starting them and things like that, we took a very Turbot-y approach, I'll say, to that, which is that we only try to stop the instance once. So, if you say stop all instances at 8 p.m. And we stop it at 8 p.m. And you start it back up at 8:15, we don't try and stop it again. So, that was how we landed on that to create some value, but not get in the way, in terms of someone that's trying to do productive work where the automation might be fighting with them.
Corey: And that's, I think, the biggest challenge. People wind up fighting with the automation. At least in the world of cost, the first time that your cost savings attempt causes an outage, you're not usually allowed to try to save money anymore. In the world of governance, where you're trying to make sure that there is something holistic across the board that feeds into compliance programs, “Yeah, it caused a problem, so we're turning it off,” That's not really an option unless you're basically Enron. So, at some point you need to learn to live with it, and building out things that are user-friendly and not user-hostile in that approach is one of the things that I think, to be blunt, differentiates you.
David: Yeah, very much so. Early on, early versions of the product wouldn't even terminate things if Turbot didn't see them spin up and they were older than x minutes, like say, 30 minutes. So, the guardrails that would do destructive things only operate on resources that were newly created, so that we didn't have a situation where an internal bad actor could configure Turbot in a way that would destroy someone's entire multi-account environment and just wipe out everything. Over the last couple years, as cost has become more and more of a factor, we started to encounter use cases—I have a customer who—really cool use case, which is that they give every internal IT employee, I think it's $50 or $100 in AWS credits, and they're allowed to spin up an account, and take whatever training classes that they want, and try out resources, try out automations and things like that: basically a sandbox for each individual. They go out to a website internally, they sign up for it, their manager approves, they get this environment, and it's deployed for them, and they can play around with it. Great use case, I love it. I love the fact that they're giving their employees tools to learn this space, and to do things, and to transform from old skills to new skills.
The problem was, is that those $50 sandboxes, the person would stop using it, and then they would still sit out there and still churn cost. So, we actually built specific controls in for them that would take enforcement action—in this particular instance—on the sandbox environments. And so, when they reached their cost limit of spend, or when they reach a specific time value—90 days, etcetera—Turbot would actually go and start terminating all resources within the account and shutting it down, getting it ready for the next person that needed a sandbox. So, basically reset the account and put it back in the hopper to be available for the next person to come along. That's a very interesting use case. It's something that initially we didn't consider because we were thinking of those enterprise use cases: dev environments, QA environments, etcetera, but that idea of kind of time-limited sandboxes, and doing that is a unique proposition, and we had to do some custom things for that customer in order to achieve it.
Corey: It really is one of those areas that is under-appreciated, the idea of building out sandbox environments. That's one of those things I've been asking for—for AWS—for years. I would love to be able to spin up an account and say, “Great, everything in this account is fine. But after a certain date, I want the whole account terminated,” to solve that problem. And then have a positive pressure style system, where I have to keep explicitly, proactively renewing that account as a developer to continue working on things is the right answer, especially if you look at where this world came out of. When you used to have to wait six weeks to get an environment spun up, and now, because it’s Cloud, you can do it the only four weeks of approvals, once you get that, you're never going to give it up because it's painful to do that. If you can automate that and get out of people's way—you're never going to succeed there by chasing people to turn things off by hand. It has to be done automatically. Building tooling that makes this happen as the default, rather than something that a human has to remember, is the only way forward.
David: Totally. And I don't know if you can hear me smiling on the other side of the microphone here, but two of my really favorite controls that we have are associated with this. So, Turbot has its own built-in CASB solution that is very similar to AWS Single Sign-On, where you can grant someone access to an account, and they have that access; they go to a website, and they log in with their SAML identity, and their two-factor authentication, and then they can just click and get single-button access to any AWS account that they have access to. So, if you're on the security team, and you've got metadata level access across every AWS account in your environment, you have a single page you can go to and just login to it. A lot of people have this: there's been some default out of the box solutions from AWS professional services for a while, and then they rolled out Single Sign-On recently, which is a great product and very much aligned to what we do there as well.
But one of the things that we do that's kind of fun with that is, you can grant access for a specific amount of time. And when I was at Johnson & Johnson, one of the things that was always a pain point for us was periodic review of access. So, your manager has to review whatever access that you have on a yearly basis—some organizations do this every 90 days but, every 90 days, every year, whatever it is, your manager has to go through and review all your access for all systems and re-approve it on that yearly basis. And if you don't do it, you're not meeting Sarbanes–Oxley requirements, and your financial reporting system is deemed insecure.
So, if you think about that use case, there's two ways to do that. One is that you provision all access centrally through a central system, and you record all that, and then you have some sort of website that you have to build that shows the manager all the access that you have in a way that they can evaluate whether it's appropriate for you to still have that or not and click that it's okay to do, etcetera. And it was just, kind of like, a very minor tweak that we did, which is, within Turbot, you can grant access for a specific amount of time. So, you can grant access for 364 days. And so, you know that if an auditor comes in and looks at anyone's access within the environment, every bit of access within the environment has been granted within the last x days because if it's over that, it will have been revoked.
And it's a great kind of hack for not having to do periodic review. If you never grant access over that amount of time—whatever your periodic review time is, so 89 days or 364 days, or whatever it is—you can be assured that your audit-ready 100 percent of the time because there is not going to be anyone in the system that has access that's growing. And in the same way, we do the same thing with our policies. So, of those 6000 policies that we were talking about, if you say, “Hey, I want to enforce encryption on all my S3 buckets, and I want to use this very specific customer-managed key,” regardless of the policy-type setting that you're doing, the setting can be time-limited. So, for that team that wants to try out that brand new AWS service that just came out, but you don't want to give them permanent access to that, you can essentially enable that service for them for 30, 60, 90 days, whatever it might be, and then at the end of that basically Turbot revoke their access, so next time they go to the console and try and use it, they're going to have to re-request extending that period of review time for themselves in order to continue to have that access. So, both those use cases in terms of doing things in a time-limited way, are really great way and hacks to solve some of these problems of, there's not enough people in the world to manually go up and follow up on all these things. But if when you're providing the thing, you're limiting the time frame for that, it just kind of solves that problem.
Corey: Yeah, it feels to me like it's the only sensible way to solve these issues. I do want to thank you for taking so much time out of your day to speak with me. If people want to learn more about Turbot. Where can they find it?
David: Yeah. Best place to go is turbot.com, our website. We have a ton of resources out there, and getting started guides. If you're interested in kicking the tires and getting things going, there's call to actions on that page to sign up for a free trial account, import one of your AWS accounts, hey run the entire CIS benchmark for AWS, Axure, GCP, whatever you want to do, against your account to report out, see how things are working. Maybe better, just do one thing. Maybe, you said, let's pick out one thing and do that within Turbot, and then see if it helps you.
Corey: I think I might actually try that myself. But that is a topic for another time. Thanks once again for taking the time to speak with me.
David: Thanks, Corey really enjoyed it.
Corey: David Boeke, CTO, and VP of services for Turbot. I am Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. Whereas if you didn't enjoy this podcast, please leave a five-star review on Apple Podcasts along with a comment explaining why it's better to do all of your governance and tagging work by hand.
Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.
This has been a HumblePod production. Stay humble.