Screaming in the Cloud - Granted, Common Fate, and AWS Functionality with Chris Norman

Episode Date: June 30, 2022

About ChrisChris is a robotics engineer turned cloud security practitioner. From building origami robots for NASA, to neuroscience wearables, to enterprise software consulting, he is a passionate builder at heart. Chris is a cofounder of Common Fate, a company with a mission to make cloud access simple and secure.Links:Common Fate: https://commonfate.io/Granted: https://granted.devTwitter: https://twitter.com/chr_norm

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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. Let's face it. On-call firefighting at 2 a.m. is stressful.

So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening. But the good news is that Incident.io makes incidents less stressful and a lot more valuable. Incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues, and learn from incident insights to improve site reliability and fix your vulnerabilities. Try Incident.io to recover faster and sleep more. This episode is sponsored in part by Honeycomb. When production is running slow,

it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other. Which one is up to you?

Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business, production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaming in the cloud. Observability, it's more than just hipster monitoring. Welcome to Screaming in the Cloud. I'm Corey Quinn. It doesn't matter where you are on your journey in cloud. You could never have heard of Amazon, the bookstore. And you encounter AWS and you spin up an account.

And within 20 minutes, you will come to the realization that everyone in this space does. Wow, logging into AWS absolutely blows goats. Today, my guest obviously had that reaction, but unlike most people I talked to, decided to get up and do something about it. Chris Norman is the co-founder of Common Fate, and most notably to how I know him, is one of the original authors of the tool Granted. Chris, thank you so much for joining me. Hey, Corey. Thank you for having me. I have done podcasts before. I have done a blog post on it. I evangelize it on Twitter constantly. And even now, it is challenging in a few ways to

explain holistically what Granted is. Rather than trying to tell your story for you, when someone says, oh, Granted, that seems interesting and impossible to Google for in isolation, so therefore we know it's going to be good, because all the open source projects with hard to find names are. What is Granted and what does it do? Granted is a command line tool which makes it really easy for you to get access and assume roles when you're working with AWS. For me, when I'm using Granted day to day, I wake up, go to my computer, working from home right now, crack open the MacBook, and I log in and do some development work. I'm going to go and start working in the cloud. Oh, when I start first thing in the morning doing development work and logging into the cloud, I know, oh great, I'm going to log into AWS. And now I know that my day is going downhill from here. Exactly, exactly. I think maybe the best

days are when you don't need to log in at all. But when you do, I go and I open my terminal and I run this command using Granted. I run this assume command and it authenticates me with single sign-on into AWS. And then it opens up a console window in a particular account. Now, you might ask, well, that's a fairly standard thing. And in fact, that's probably the way that the console

and all of the tools work by default with AWS. Why do you need a third-party tool for this? Right. I've used a bunch of things that do varying forms of this. And unlike Granted, you don't see me gushing about them. And I want to be very clear, we have no business relationship. You're not sponsoring anything that I do. I'm not entirely clear on what your day job entails, but I have absolutely fallen in love with the granted tool, which is why I'm dragging you onto this show, kicking and screaming, mostly to give me an excuse to rave about it some more. Exactly. And thank you for the kind words. And I'd say really what makes it special or why I've

been so excited to be working on it is that it makes this access, particularly when you're working with multiple accounts, really, really easy. So when I run Assume and I open up that console window, you know, that's all fine. And that's very similar to how a lot of the other tools and projects that are out there work. But when I want to open that second account and that second console window, maybe because I'm looking at like a development and a staging account at the same time, then Granted allows me to view both of those simultaneously in my browser. And we do that using some platform sort of tricks and building into the way that the browser works. Honestly, one of the biggest differences in how you describe what Granted is and how I view it is when you describe it as a CLI application. Because, yes, it is that.

But one of the distinguishing characteristics is you also have a Firefox extension that winds up leveraging the multi-container functionality extension that Firefox has. So whenever I wind up running a single command, assume with a dash C flag, then I give it the name of my AWS profile, it opens the web console so I can click ops to my heart's content inside of a tab that is locked to a container, which means I can have one or two or 20 different AWS accounts and or regions up running simultaneously side by side, which is basically impossible any other way that I've ever looked at. Absolutely. Yeah. And that's like the big differentiating factor right now between Granted and between the sort of default, the native experience, if you're just using the AWS command line by itself. With Granted, you can, with these Firefox containers, all of your cookies, your

profile, everything is all localized into that one container. It's actually, it's a privacy features that are built into Firefox, which keeps everything really separate between your different profiles. And what we're doing with Granted is that we make it really easy to open specific profiles that correspond with the different AWS profiles that you're using. So you have one, which could be your development account, one which could be your development account, one which could be production or staging, and you can jump between these and navigate between them just as separate tabs in your browser, which is a massive improvement over what I've previously had to use in the past.

The thing that really just strikes me about this is, first, of course, the functionality and the rest. So I saw this, I forget how I even came across it, and immediately I started using it on my Mac. It was great. I started using it when I was on the road, and it was less great. Because you built this thing in Go, it can compile and install on almost anything, but there were some assumptions that you had built into this in its early days that did not necessarily encompass all of the use cases that I use. For example, it hadn't really occurred to you that some lunatic would try and only use an iPad when they're on the road. So they have to be able to run this to

get federated login links via SSHing into an EC2 instance running somewhere and not have it open locally. You seemed almost taken aback when I brought that up. Like, what lunatic would do that? Like, hi, I am such a lunatic. Let's talk about this. And it does that now. And it's awesome. It does seem to me though, and please correct me if I'm wrong on this assumption slash assessment, that this is first and foremost aimed at desktop users, specifically people running Mac on the desktop. Is that the genesis of it? It is indeed. And I think part of the cause behind that is that we originally built the tool for ourselves. And as we were building things and as we were working

using the cloud, we were running things. We like to think that we're following best practices when we're using AWS. And so we'd set up multiple accounts. We'd have a special account for development, a separate one for staging, a separate one for production, even internal tools that we would build. We would go and spin up an individual account for those. And then, you know, we had lots of accounts and to go and access those really easily was quite difficult. So we definitely, we built it for ourselves first. And I think that that's part of when we released it was still actually a little bit of cause for some of the initial problems and some of the feedback that we had was that it's great to build tools for yourself, but when you're

working in open source, there's a lot of different diversity with how people are using things. If you take different approaches, you wind up trying to align with existing best practices, whereas I am a loudmouth white guy who works in tech. So what I do definitionally becomes a best practice in the ecosystem. It's easier to just comport with the ones that are already existing with smart people put together rather than just trying to confidence your way through it. So you took the better path than I did, but there's been a lot of evolution to granted as I've been using it for a while. I did a whole write-up on it and that got a whole bunch of eyes onto the project, which I can now admit was a nefarious plan on my

part, because popping into your community Slack and yelling at you for features I want was all well and good, but let's try and get some people with eyes on this who are smarter than me, which is not that high of a bar when it comes to SSO and IAM and federated login and the rest, and they can start finding other enhancements

that I'll probably benefit from. And sure enough, that's exactly what happened. My sneaky plan has come to fruition. Thanks for being a sucker, I guess. It worked. I'm super thrilled by the product. I guess it's a great thing, I think, that the feedback, and particularly something that's always been really exciting,

is just seeing new issues come through on GitHub, because it really shows the kinds of interesting use cases and the kinds of interesting teams and companies that are using Granted to make their lives a little bit easier. When I go to the website, which again is impossible to Google, the website for those wondering is granted.dev.

It's short, it's concise. I can say it on a podcast and people automatically know how to spell it. But at the top of the website, which is very well done, it's concise, I can say it on a podcast, and people automatically know how to spell it. But at the top of the website, which is very well done, by the way, it mentions that, oh, you can govern access to break glass rolls with CommonFate Cloud. And it also says in the drop shadow nonsense thing

in the upper corner, brought to you by CommonFate, which is apparently the name of your company. So the question I'll get to in a second is what does your company do? But first and foremost, is this going to be one of those rug pull open source projects where one day it's, oh, you want to log into your AWS accounts that they insert quarter to continue. I'm mostly being a little over the top with that description, but we've all seen things that we love turn into molten garbage. What is the plan around this? Are you about to ruin this for the rest of us once you wind up

raising a round or something? What's the deal? Yeah, it's a great question, Corey. And I think that to a degree, releasing anything like this that sits in the access workflow and helps you assume roles and helps you day to day, we have a responsibility to uphold stability and reliability here and to not change things. And I think part of like not changing things includes not rug pulling, as you've alluded to. And I think that for some companies, it ends up that open source becomes like a kind of a lead generation tool or you end up with, you know, now finally, let's go and add another

login so that you have to log into CommonFate to use Granted. And I think that, to be honest, a tool like this where it's all about improving the speed of access, the incentives for us, like it doesn't even make sense to try and add another login to try to get people to like, to say, log into CommonFate because that would make your sign-in process for AWS take even longer than it already does. Yeah, you decided that, you know, what's the biggest problem? Oh, you can sleep at night. So let's go ahead and make it even worse. Now I want you to be this custodian of all my credentials to log into all of my accounts. And now you're going to be critical past. So if you're down, I'm not able to log into anything. And oh, by the way, I have to trust you with full access

to my bank stuff. I just can't imagine that that is a direction that you would be super excited about diving headfirst. No, no. Yeah, certainly not. And I think that building anything in this space and with what we're doing with CommonFate, we're building a cloud platform to try to make IAM a little bit easier to work with. But it's really sensitive around granting any kind of permission. And I think that you really do need that trust. So trying to build trust, I guess, with our open source projects is really important for us to, with Granted and with this project, that it's going to continue to be reliable and continue to work as it currently does. The way I see it, one of the dangers of

doing anything that is particularly open source or that leans in a direction of building in Amazon's ecosystem, it leads to the natural question of, well, isn't this just going to be, some people say stolen, and I don't think those people understand how open source works, by AWS themselves? Or aren't they going to build something themselves at AWS that's going to wind up stomping this thing that you've built. And my honest and remarkably cynical answer is, is that you have built a tool that is a joy to use that makes logging into AWS accounts streamlined and efficient in a variety of different patterns. Does that really sound like something AWS would do? And followed by, i wish they would this everyone would benefit from that rising tide i have to be very direct and very clear your product should not exist this should be something

the provider themselves handles but nope instead it has to exist and while i'm glad it does i also can't shake the feeling that i am incredibly annoyed by the fact that it has to. Yeah, certainly, certainly. And it's something that I think about a little bit. I like to wonder whether there's maybe like a single feature flag or some single sort of configuration setting in AWS where they're not allowing different tabs to access different accounts. They're not allowing this kind of concurrent access. And maybe if we make enough noise about Granted, maybe one of the engineers will go and flick that switch and they'll just enable it by default. And then Granted itself will be a lot less relevant. But for everybody who's using AWS, that'll be a massive win because the big draw of using Granted

is mainly just around being able to access different accounts at the same time. If AWS let you do that out of the box, hey, that would be great. And I'd have a lot less stuff to maintain. Originally, I had you here to talk about Granted, but I took a glance at what you're actually building over at CommonFate. And I'm about to basically hijack slash derail

what probably is going to amount to the rest of this conversation. Because you have a quick example on your site by developers for developers. You show a quick Python script your site by developers for developers. You show a quick Python script that tries to access a S3 bucket object, and it's denied. You copy the error message.

You paste it into what you're building over at CommonFate. And in return, it's like, oh, yeah, this is the policy that fixes it. Do you want us to apply it for you? And I just about fell out of my chair because I have been asking for this explicit thing for a very long time, And AWS doesn't do it. Their IAM access analyzer claims to like, oh,

we're just going to look at CloudTrail and see what permissions it uses and we'll build a policy to scope it down. Okay. So it's S3 access. Fair enough. To what object or what bucket? Guess is what it tells you there. And it's, this is crap. Who thinks this is a good user experience? You have built the thing that I wish AWS had built in natively. Because let's be honest here, I do what an awful lot of people do

and overscope permissions massively just because messing around with the bare minimum set of permissions in many cases takes more time than building the damn thing in the first place. Oh, absolutely. Absolutely. And in fact, this was a few years ago when I was consulting, I had a really similar sort of story where one of the clients that we were working with, the CTO of this company, he was needing to grant us access to AWS. And we were needing to build a particular service. and he said

okay can you just let me know the permissions that you'll need and I'll go and deploy the role for this and I came back and I said wait I don't even know the permissions that I'm going to need because the damn thing isn't even built yet so we went by sort of back and forth around this and the compromise ended up just being you know way too much access and that was sort of part of the the inspiration for you know really this whole project and with what we're building with common fate just trying to make that that feedback loop around getting to the right level of permissions a lot faster yeah i am just so overwhelmingly impressed by the fact that you have built and please don't take this as a criticism, but a set of very simple tools.

Not simple in the terms of, oh, that's like three lines of bash and a fool could write that on a weekend. No, simple in the sense of it solves a problem elegantly and well, and it's straightforward, well, straightforward as anything in the world of access control goes, to wrap your head around exactly what it does. You don't tend to build these things by sitting around a table brainstorming with someone you met at co-founder dating pool or something and wind up figuring, oh, we should go and solve that. That sounds like a

billion dollar problem. This feels very much like the outcome of when you're sitting around talking to someone and let's start by drinking six beers so we become extraordinarily honest, followed immediately by, let's talk about what sucks, what pisses you off the most. It feels like this is sort of the low-hanging fruit of things that upset people when it comes to AWS. I mean, if things had gone slightly differently, instead of focusing on AWS bills,

IAM was next on my list of things to tackle just because I was tired of smacking my head into it. This is very clearly a problem space that you folks have analyzed deeply, worked within, and have put a lot of thought into. I want to be clear, I've thrown a lot of feature suggestions at you

for granted from start to finish, but all of them have been around interface stuff and usability and expanding use cases. None of them have been around interface stuff and usability and expanding use cases. None of them have been, well, that seems screamingly insecure because it hasn't. It has been effective start to finish. I think that from a security posture, you make terrific choices, in many cases, better than ones I would have made starting from scratch myself. Everything that I'm looking at and what you have built is from a position of, this is absolutely amazing and it is transformative to my own workflows. Now, how can we improve it?

Thank you, Corey. And I'll say as well, maybe around the security angle, that one of the goals with Granted was to try and do things a little bit better than the default way that AWS does them when it comes to security. And it's actually been a bit of a source for challenges with some of the users that we've been working with with Granted because one of the things we wanted to do was encrypt the SSO token. And this is the token that when you sign in to AWS,

it's kind of like it allows you to then get access to all of the rest of the accounts. So it's like a pretty, it's a short-lived token, but it's a really sensitive one. And by default, it's just stored in plain text on your disk. So it'll just be dumped to a file and anything that can go and read that, they can go and get it. It's also a little bit hard to revoke and to lock people out. There's not really great workflows around that on AWS's side.

So we thought, okay, great. One of the goals for granted can be that we'll go and store this in your keychain in your system and we'll work natively with that. And that's actually been a cause for a little bit of a hassle for some users, though, because by doing that and by storing all of this information in the keychain, And that's actually been a cause for a little bit of a hassle for some users, though, because by doing that and by storing all of this information in the keychain, it's actually broken some of the integrations with the rest of the tooling, which kind of expects tokens and things to be in certain places.

So we've actually had to, as part of dealing with that, we've granted, we've had to give users the ability to opt out for that. DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their application

suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business confidence and peace of mind. Read the full success story at snark.cloud slash chronosphere. That's snark.cloud slash c-h-r-o-n-o-s-p-h-e-r-e. What I find is so, I think just across the board, fantastic. You are very clearly engaged with your community. There's a community Slack that you have set up for this. And I know, I know, too many Slacks. Everyone has this problem. This is one of those that is worth hanging around in, at least from my perspective, just because one of the problems that you have, I suspect, is on my Mac, it's great because I wind up automatically updating it to whatever the most recent one is every time I do a brew upgrade. But on the Linux side of the world,

you've discovered what many of us have discovered, and that is that packaging things for Linux is a freaking disaster. The current installation is great. Here's basically a curl bash, or grab this tarball and install it, and that's fine. But there's no real way of keeping that updated and synced. So I was checking the other day, and oh, wow, I'm something like eight versions behind on this box. But it still just works. I upgraded. Oh, wow, there's new functionality here. This is stuff that it still just works. I upgraded. Oh, wow.

There's new functionality here. This is stuff that's actually really handy. I like this quite a bit. Let's see what else we can do. I'm just so impressed start to finish by just how receptive you've been to various community feedbacks. And as well, I want to be very clear on this point too. I've had folks who actually know what they're doing in an InfoSec sense, look at what you're up to, and none of them had any issues of note. I'm sure that they have a pile of things

like, well, with that curl bash, they should really be doing a GPG check. Yes, yes, fine, whatever. If that's your target threat model, okay, great. You're in reality land for what I do. This is awesome. And they don't seem to have any problems oh yeah and by the way sending analytics back up which okay fine whatever and it's not disclosing them okay that's bad and it's including the contents of your aws credentials ah i did encounter something that was doing that on the back end was serverless framework sorry something caught in my throat for a second there no faster way I could think of to erode trust than that. But everything you're doing just makes sense. Oh, I do remember that. And that was a little bit of a fiasco really around all of that, right?

And it's great to hear actually around the InfoSec folks and security people being not unhappy, I guess, with a tool like this. It's been interesting for me personally. We've really come from a practitioner's background. I wouldn't call myself a security engineer at all. I would call myself sometimes a software developer, I guess. I've been hacking my way around Go and definitely learning a lot about how the cloud has worked over the past seven, eight years or so. But I wouldn't call myself a security engineer. So being very cautious around how all of these things work. And we've really tried to defer to things like the system key chain and defer to things that we know

are pretty safe and work. The thing that I also want to call out as well is that you're licensing this under the MIT license. This is not one of those, oh, you're required to wind up doing a bunch of branding stuff around it. And they simply say, oh, you have to own the trademark for all of these things. I mean, I'm not an to own the trademark for all of these things. I mean, I'm not an expert in international trademark law, let's be very clear. But I also feel that trademarking a term that is already used heavily in the space, such as the word granted, feels like kind of an uphill battle. And let's further be clear that it doesn't matter what you call this thing.

In fact, I will call attention to an oddity that I've encountered a fair bit. After installing it, the first thing you do is you run the command granted. That sets it up. It lets you configure your browser, what browser you want to use. And it now supports standard out for that headless EC2 use case. Great. Awesome. Love it.

But then the other binary that ships with it is assume. And that's what I use day to day. It actually takes me a minute sometimes when it's been long enough to remember that the tool is called granted and not assume. What's up with that? So part of the challenge that we ran into when we were building the granted project is that we needed to export some environment variables. And these are really important when you're logging into AWS because you have your access key, your secret key, your session token, all of those when you run the assume command need to go into the terminal session that you called it. This doesn't matter so much when you're using

the console mode, which is what we mentioned earlier, where you could open 100 different accounts if you want to view all of those at the same time in your browser. But if you want to use it in your terminal, we wanted to make it like as really smooth and seamless as possible here. And we were really inspired by this approach from, and I have to shout them out and kind of give credit to them, a tool called AWS Sume. They're spelled A-W-S-U-M-E, Python-based tool that they don't do as much with single sign-on, but we thought they had a really nice general approach to the way that they did the scripting and aliasing. And we were inspired by that. And part of that means that we needed to have a shell script that called this executable, which then would export things back out into the shell script.

And we're doing all this wizardry under the hood to make the user experience really smooth and seamless. Part of that meant that we separated the commands into granted and assume. And the other part of the naming for everything is that I felt granted had a far better ring to it than calling the whole project assume. True. And when you say assume, is it AWS or not? I've used the

Awesome project before. I've used AWS Vault out of 99 Designs for a while. I've used, for three minutes, the native AWS SSO config, and that is just trash. Again, they're so good at the plumbing, so bad at the porcelain, I think is the criticism that I would levy toward a lot of this stuff. And it's odd in that to think there's an entire company built around just smoothing over these sharp, obnoxious edges. But I'm saying this as someone who runs a consultancy and have five years that just fixes the bill for this one company. So there's definitely a series of cottage industries

that spring up around these things. I would be thrilled on some level if you wound up being completely subsumed by their product advancements, but it's been 15 years for a lot of this stuff and we're still waiting. But my big failure mode that I'm worried about is that you never are.

Yeah, exactly, exactly. And it's really interesting when you think about all of these user experience gaps in AWS being opportunities for, I guess, for companies like us and trying to simplify a lot of the complexity for things. I'm interested in sort of waiting for a startup to try and like rebuild the actual AWS console itself to make it a little bit faster and easier to use. It's been done and attempted a bunch of different times. The problem is that the console is a lot of different things to a lot of different people. And as you step through that, you can solve for your use case super easily. Yeah, what do I care?

I use RDS, I use some VPC nonsense, and I use EC2, the end. Great. What about IAM? Because I promise you're using that, whether you know it or not. And okay, well, I'm talking to someone else who's DynamoDB and someone else is full-on serverless and someone else has more money than cents. So they mostly use SageMaker and so on and

so forth. And it turns out that you're effectively trying to rebuild everything. I don't know that that necessarily works. Yeah. And I think that that's a good point around maybe why we haven't seen anything around that sort of space so far. You go to the console and you click down, you see that list of 200 different services, and all of those have had teams go and actually build the UI and work with those individual APIs. Any ideas as far as what's next for features on Granted? I think that for us, it's continuing to work with everybody who's using it and with a focus of stability and performance. We actually had somebody in the community raise an issue because they have an AWS config file that's over 7,000 lines long. And I kind of pity that person potentially for their day-to-day.

They must deal with so much complexity. Granted, it's currently quite slow when the config files get very big. And for us, I think we built it for ourselves. We don't have that many accounts just yet. So working to try to make it really performant and really reliable is something that's really important. If you don't mind a feature request while we're at it, and I understand that this is more challenging than it looks like. I'm willing to fund

this as a feature bounty, if that makes sense. And this also feels like it might be a good first project for a very particular type of person. I would love to get tab completion working in ZSH. You have it for Fish, because there's a great library that automatically populates that out, but for the ZSH side of it, it's, oh,

I should just wind up getting ZSH completion working, and i fell down a rabbit hole let me tell you and i come away from this with the perception of yeah i'm not gonna do it i am not smart enough to check those boxes but a lot of people are so that is the next thing i would love to see because i will change my browser to log into the aws console for you but be damned if i'm changing my shell. I think autocomplete probably should be higher on our roadmap for the tool, to be honest, because it's really like the key metric and what we're focusing on is how easy is it to log in? And, you know, if you're not too sure what commands

to use, or if we can save you a few keystrokes, I think that that would be kind of like reaching our goals. From where I'm sitting, you definitely have. I really want to thank you for taking the time to not only build this in the first place, but also speak with me about it. If people want to learn more, where's the best place to find you? So you can find me on Twitter. I'm chr underscore norm, or you can go and visit granted.dev and you'll have a link to join the Slack community. And I'm very active on the Slack. You certainly are, although I will admit that I fall into the challenge of being in just the perfectly opposed time zone from you and your co-founder, who are in different time zones, to my understanding. One of you is in Australia, and one of you is in London. You're the London

guy, as best I'm aware. And as a result, invariably, I wind up putting in feature requests right when no one's around and for better or worse the middle of the night is not when I'm usually awake trying to log into AWS. That is Azure time. Yeah, we don't have the US time zone properly covered yet for our community support and help but we do have a fair bit of the world time zone covered. The rest of the team for Common Fade is all based in Australia, and I'm out here over in London. Yeah, I just want to

thank you again for just being so accessible and, like, honestly, receptive to feedback. I want to be clear, there's a way to give feedback, and I do strive to do it constructively. I didn't come crashing into your Slack one day with a, you know what your problem is? I prefer to take the, this is awesome, here's what I think would be even better. Does that make sense? As opposed to the imperious demands and GitHub issues and whatnot. It's, I'd love it if it did this thing. It doesn't do this thing. Can you please make it do this thing? Turns out that's the better way to drive change. Who knew? Yeah, definitely. And I think it's one of the things that's been the best around our journey with Granted so far has been listening to feedback and hearing from people how they would like to

use the tool. And a big thank you to you, Corey, for actually suggesting changes that make it not only better for you, but better for everybody else who's using Granted. Well, as long as they're using my particular Byzantine workload patterns in some way or shape or form, I'll hear that. But no, it's been an absolute pleasure. And I really want to thank you for your time as well. Yeah, thank you for having me. Chris Norman, co-founder of Common Fate, as well as one of the two primary developers

originally behind the Granted project that logs you into AWS without you having to lose your mind. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, incensed, raging comment that talks about just how terrible all of this is once you spend four hours logging into your AWS account by hand first. If your AWS bill keeps rising and your blood

pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble