As a Developer, How do you manage the users that can access the system? Jonathan and Will share some pointers and approaches on how you can protect your system or account from being accessed by multiple or anonymous users. 

 

Hey everybody. Welcome to adventures in DevOps

 

We'll, um, hey, everyone. Welcome to another episode. I'm sure that's

 

All right.

 

how NSYNC got started too.

 

Yeah, awesome, that was fun. So I'm Jonathan.

 

I'm Will.

 

Welcome.

 

Yeah, we were formerly the co-hosts of the Adventure and DevOps show, but that may be coming to an end here in the near future based on the start of this episode.

 

If so, it's been nice knowing you. See you on the other side, guys.

 

Yeah.

 

So, we're gonna talk about user management, I think. Is that right?

 

That is correct. Yeah, user management from the perspective of, how do you control who has access? We initially started before we started recording talking about access to AWS, but it extends a lot further than that. Who has access to your GitHub repos and your Cloudflare account and. other cloud providers and SaaS services. And this came up recently for me because I'm going through this process of backfilling and changing how we grant and audit access to our accounts. And so I personally am putting it into Terraform. because Terraform has great support for AWS, but they also have support for things like GitHub and Cloudflare and several other providers and organizing it in a way so that each user in our organization has a Terraform file and that Terraform file states what accounts they have, what groups they're a member of, and then the groups define what permissions they have in there. which gives you a way to audit who has access at any given time and then through your Git history, be able to identify changes to the permissions that that person has. But yeah, it kind of brought up a larger question of how do you manage users?

 

Yeah, it's an important question and it's not an easy one to answer because there's a lot of pieces that go into it, right? I mean, it's not just a matter of like, oh, how do we store passwords or how do we generate passwords or whatever. There's a lot more that goes into it. So you're using Terraform with... AWS, which I'm sure you could also do with Azure or Google Cloud or Digital Ocean or whatever other cloud provider you might be using.

 

That's right.

 

I have experience. So, I haven't done that per se at that level. The company I'm working with right now, we may be doing that. I know that we're using Terraform for a lot of stuff, and we're not done yet implementing Terraform. So, I don't know if that's been accomplished yet or not. But it's kind of a no-brainer to me that it should be done that way. So I guess you don't have to convince me.

 

Hahaha!

 

But where I've done something similar in the past is at a company a few years ago, we were using our own self-hosted GitLab instance. And we did essentially the same thing for our users there, our users in groups and permissions there. So, you know, GitLab gives you a pretty extensive, just the same as GitHub. You have a lot of permissions you can set. You can go in and give read or write permission or whatever to a particular user. You can put users in groups and those groups can be member, can have repositories within them and so on. GitLab has a little bit different model than GitHub, but it's similar in concept, of course. But it's a lot of manual toil to go in and change that, and especially onboarding or offboarding or somebody changes teams, which is sort of a mix of on and offboarding at the same time. These are all annoying and almost impossible if you have a large organization. It's almost impossible to do it correctly. I mean, if you have a thousand people in your company and Bob leaves and he was say in accounting, but before that he was in marketing and before that he was in sales or whatever, you have to go back through at every place where he might have had permissions and remove that and that's a huge pain in the butt. So the way we did this with GitLab, which had one of our repos, was like the GitLab configuration repo. And it had a CI script that ran every hour, I think it was every hour, to just whatever, it just set everything every hour. So you could go into the interface and change your permissions or add Bob to your group, but top of the next hour, it goes back to whatever's in that repo. So if Bob wasn't in that repo, he's not in your group anymore.

 

Which is great if you're going to help desk roll and your performance is based on the number of tickets you close. I mean, you can just work that system all day long. The limiting

 

Yeah.

 

factor there is how many times is Bob willing to open a ticket before he's like, dude, what is up?

 

Yeah. But yeah, that was really great. And then when it's time to onboard, you just go to that repo and you add the person to the group they belong in or whatever. When it's time to offboard, it's even simpler. You just look for Bob and delete him. And it's all in one place.

 

Right.

 

You don't have to go look around manually through all these different interfaces or whatever. It's just one place, delete Bob and you're done.

 

Yeah, in the past I've had like the HR approved spreadsheets, you know, with the onboarding and offboarding checklist. And sometimes that's been like its own project in your project management system and different things like that. And even some of the tools, like if you use enterprise level tools like Okta where you do single sign on and stuff. I mean, that's still a, that's a single place to manage it from, but one of the gaps that it still leaves is, okay, let's open up Okta right now. How do we know that everyone who's set up here is actually supposed to have this level of access?

 

Mm-hmm. Oh, I hate that.

 

And I think that's one of the key, yeah, I think that's one of the key things I'm trying to address here by putting this into a GitOps style workflow.

 

Yeah, I mean, I can't count the number of times I've been in a new system, maybe I'm on board or whatever. And I'm in management roles now, so I kind of have the responsibility to make sure that things aren't going crazy. And I get into, say, my GitHub account, and I see there's 50 people there, and I only know half the names. And I don't know, is this somebody who used to work here,

 

Hahaha

 

or are they a contractor, or is this a bot account? You don't know sometimes, and it's... so infuriating, you know, you don't know if there's somebody's hacked their way into your system, or if it's legitimate.

 

Yeah, for sure. Yeah, and that just opens up a whole can of worms. Like, how do we manage this? How do we deal with it?

 

So aside from putting it into Terraform or something similar, some sort of infrastructure as code or accounts as code, are there other approaches you have used or would use to help mitigate some of these concerns and make lives easier?

 

Yeah, just off the top of my head, I'm using Terraform, but mainly because that's just the tool of choice where I'm at. You could also use Ansible or Puppet or Chef. Does anyone actually use Chef anymore?

 

Uh, the Muppets do, I think.

 

Right? But yeah, like any of the infrastructure as code tools, I think, would work. And then I think there are tools for managing this, like Okta, that we've already mentioned. And AWS has AWS organizations and SSO. But even those two specifically, while you can add someone to it and assign their access based on group membership, it still leaves the gap of when you open the console, how do you know that everyone there has the access they're supposed to have? And I think that's the part that I keep coming back to, which is just putting me back to Terraform because then you can look at it and say, you can just run Terraform and Terraform is going to say, yeah, everything matches what I'm told it should be. Or no, this account has access to a group membership that I don't know about.

 

Yeah, yeah. Yeah, the tool, the tools, the code tool, infrastructure's code tool is a lot as important in the concept, right? I like, you know, I'm... I'm curious what you think about the idea. Like where would you store this metadata about a user? Should that live in comments in your Terraform file? To just say, you know, this is a bot user created for this thing, or this is Bob, who's a temporary contractor, he joined for six months and you can delete his account when he leaves, you know, those sorts of things. So you don't have this situation where like, who is Bob and why does he have an account? Where would you put that sort of data?

 

Yeah, I'm currently putting it in the Terraform file for that specific resource. Almost every Terraform resource has a description field, and I'm trying to leverage that. for a couple of reasons. You can obviously just put a comment in the file, but I've found that using the description field, a lot of Terraform resources will map that over to the place where they're building it. So if you create a user in, an AWS user in Terraform and you set the description field, then whenever it builds that AWS resource, it actually populates the description field there as well. So. You've got this description that travels with the user wherever you happen to be looking at them from.

 

Yep, that's good, that's good.

 

And then the other side of that is. Commit messages I think are really handy and also whenever you create a new branch in your git repo both of those I reference the ticket because ideally you shouldn't be making changes to any user's account or creating and deleting user accounts. without a ticket from your ticketing system referencing why you're doing that work. And so in my commit message and when I create the git branch to reflect that work, I'll include the ticket ID in both of those. And then if you have your ticketing system integrated with your ticket, you can see that the ticket is integrated with your ticket. So you can see that the ticket is integrated with your ticket. And then if you have your ticket, your GitHub organization, you can use keywords like closes ticket number 123 and whenever that PR gets merged into the main branch it will automatically resolve that ticket for you

 

Right.

 

in the ticketing system. So you get some like little nice features that help incentivize you to follow that pattern as well.

 

And then is your Terraform script is automatically applied on every commit or is that handled manually?

 

So we're using Terraform Cloud. And so whenever you merge to main, you open your pull request. It will run a Terraform plan to show you the resource changes that it's going to make. And then if that looks right, you can merge that in. And then that will queue up the execution over in Terraform Cloud. So right now, you still have to go over to Terraform Cloud and apply the changes from there. But I have seen, I've actually got some personal repos integrated with Terraform where when you merge that pull request in. through GitHub, you can actually apply it from GitHub itself. And we don't have that set up yet. I believe to set that up, you have to have the Terraform app installed in your GitHub organization, which we may not have done over here. But that's the same thing. You still have to manually apply the change. But it does save you a step from having to go over to Terraform Cloud and apply it. You can just do it right from the pull request screen.

 

We had a tool, I don't remember the name of it, that did that for GitLab, the same company I was mentioning before. I've always found it a little bit, I mean, I kind of understand the reason, but it's a little bit annoying that you can't just trust your CI pipeline to automatically validate and deploy things for you, that there's still some manual step there. Anyhow, the reason is because you can actually quite easily make a mistake that like, oh, let's delete the Kubernetes cluster. and it's automatically deployed.

 

Alright.

 

You know, it's a valid Terraform file, so it doesn't like screw up the linters, but then, oh, whoops, Kubernetes is gone.

 

Right?

 

All of our customers are gone.

 

Yeah, it was totally valid. It was 368 delete operations, but they were all 100%

 

Exactly.

 

valid.

 

Yeah. So I'm sure that we'll have better tooling and some of them probably already exist to automate some of that, make sure that only certain types of changes are permitted to happen automatically. But that's one thing I've seen. I've yet to see, not that my experience is super extensive, but I've yet to see a completely automated Terraform deployment anywhere. They probably exist, but I've not seen them yet for these reasons.

 

Yeah, I know over in Terraform Cloud, there's a checkbox to enable that says, just go ahead and apply when you merge to main. And we don't have that checked. But I'm assuming if you do check it, then it's going to do just that.

 

Yep. Yep.

 

Which at a high level, I think that's probably fairly safe to turn on because we run the Terraform plan when the pull request is opened. So whoever approves the PR has visibility into what Terraform thinks its next steps are going to be.

 

Right. I think the problem though is that sometimes that plan, if you're expecting, you know, sometimes those plans are not easy to, they're easy to miss details.

 

Yeah.

 

You know, you might, you might actually, you know, if you accidentally rename a bucket or something, or, you know, sometimes it's not obvious that you're deleting one and creating a new one, especially if you do several changes at once. So I think that's part of the problem. For small changes, and if you're limiting yourself to say, maybe you have a specific Terraform directory that's only for user permissions, maybe you trust that one all the time. I mean, even if you met something up and deleted a user, it's usually pretty easy to recreate it or re-add permissions or something like that. You're not gonna make permanently destructive changes like deleting a database or something like that. So.

 

Yeah, for sure. I think that falls into the more of an organizational best practices. And how do you build your repos? What's the scope of responsibility for a repo?

 

Exactly.

 

And then just as far as like. best practices in our team, we've agreed that we're going to do small incremental commits and try to refrain from those big monster commits that change hundreds or thousands of lines of code in a single commit. Although

 

Yeah.

 

sometimes, you know...

 

Sometimes a one line change can have a 500 line plan change though. And that's where it gets complicated with Terraform.

 

Yeah, true. Yeah, agreed.

 

So when you're creating these users, I'm curious, do you always use groups or do you sometimes assign users a specific permission directly? What's your philosophy on that?

 

I lean towards always groups and the reason is because I've been burned so many times of like, oh this one person just needs this one thing, but then someone else starts helping them and then someone else starts helping them and like there's this scope creep that goes along and over time you end up juggling these permissions across multiple user accounts or They get different permissions because it's not all consolidated in one place. So it seems a little excessive at first. But even if I'm going to make a change for one person, I will either do so by modifying an existing group or create a new group to address that need. And then the policies and the roles and the permissions are applied to the group, not to the user.

 

I prefer the group approach as well for all those reasons and others. Aside from infrastructure as code, somebody left the company I'm working for a couple months ago and I had to go remove their GitHub account. But of course, I'm not deleting their GitHub account because they have their own GitHub account.

 

Great. Great.

 

So I had to literally go through every project in our group and see if he had direct personal access to anything. And he did on several things. because he wasn't just given group access. So especially for public services, like if you're using Jira's cloud or GitHub or something like that, not using groups is a recipe for disaster, in my opinion.

 

Yeah, absolutely.

 

What else can we talk about? I had another question I forgot about but I'll try to remember it before we end.

 

Well, while you remember it, I think it's a great opportunity to encourage anyone listening. How do you manage group permissions? Or if you could change them, what would you do differently? And we have our new Reddit group to handle discussions. So there is a Reddit forum. called, oddly enough, Adventures in DevOps. So if you're

 

Whoa.

 

a Reddit user, you can head over there. You can leave your comments, ask questions, and then the most upvoted questions will batch those up and actually answer those on an upcoming Q&A episode. So

 

us.

 

Reddit Adventures in DevOps.

 

it out. And if you're not a Reddit user, now's your chance to become one. It's free. You

 

That's the right show name, right? Yeah.

 

don't have to pay anything.

 

It is free. It is free, absolutely. And it's actually pretty useful. I mean, I tend to get a lot of good information off of Reddit.

 

You know, when I'm feeling too good about myself, I like to go post on there.

 

Right? Ha ha ha ha.

 

When I've had a good day on Twitter and I need to reality check.

 

Ha ha ha ha. There was a meme a while back. Someone said, yeah, I post questions on Reddit, but then immediately log in as my other Reddit account and post an answer that is just absolutely horribly wrong. Because no one will take the time to answer a question, but everyone will jump on to tell you how wrong your answer is.

 

Exactly, yeah.

 

I was like wow that's actually pretty brilliant.

 

So I didn't remember my other question. And that was, how do you see single sign-on fitting into all of this question of user management?

 

So I think single sign-on is, we use it over at Polygon. I think it's the tool, you know, there's two parts to this. There's authentication and authorization. I think single sign-on solves the authentication part of who you are. And then we use the Terraform infrastructure as code for the authorization. Saying, okay, we know who you are. But here's what you can and can't do. And single sign-on is great just because you've got all these different systems. Everyone uses Google Suite or G Suite for your email. And then you have AWS access and Cloudflare access. And all these data dog access, all these different third party providers, which results in a bunch of different user accounts, or you just do the SSO integration and handle it from one place.

 

Yeah, I agree. Of course, so if you have your single sign-on tied to your company account, that's great because then when you leave the company or whatever, just delete that account or disable the account and then all your company access is disabled. If you're using a public services like GitHub, it's a little more complicated. But still, single sign-on, I think, is a good simplification step. So you don't have to, I mean, just like you were talking about your onboarding and offboarding checklists. who wants to go through the 30 apps that your company has accounts on and make sure that Bob doesn't still have an account on sentry.io and on Atlassian and at GitHub and all the other different places. It's just nonsense to have to do that if you don't have to.

 

Yeah, even tracking what apps do we have. Some places that's a challenge,

 

Definitely.

 

especially whenever you look at a higher level company perspective, because in software engineering, OK, we probably know most of the tools that we're using. But then you bring in marketing and finance and all of those teams, and it just becomes unmanageable within a matter of minutes.

 

Definitely.

 

The one thing that has come up recently specific to GitHub because almost everyone brings their own GitHub user account to their job, there was a discussion about, well, should we have people create a new GitHub user account specific for our company? And we ended up not doing that because your GitHub profile is almost. more important than your resume these days.

 

Mm-hmm.

 

You know, so it was crippling to the future careers of people to mandate that they set up a new GitHub account or that we set up a new GitHub user for them and granted them access to it.

 

Yeah, I think I would, if somebody asked me to create a new GitHub account, I would be very, I mean, I don't know if I would refuse to, but I'd be like, that's strange. I mean, I'll add my new company email to my existing GitHub account, no problem.

 

Yeah, for sure. Great.

 

And I'll set up my email preferences so that the stuff for that group goes to my work email and my private stuff goes to my private email. But a separate account entirely? I don't know. I wouldn't be excited about it for sure.

 

Yeah, definitely. Totally agree with that.

 

Anything else we should talk about with user management?

 

Um,

 

I feel like we hit the highlights,

 

probably.

 

but there's probably something we're missing.

 

Oh, you know what else I wanted to touch on?

 

Yeah.

 

The thing that really grinds my gears.

 

Oh, this one sounds good.

 

Ha ha ha ha. 2FA.

 

Ah.

 

I am just anti-current 2FA patterns. Like so many authentication services are. saying hey here's 2FA and you need to use Google Authenticator or we'll just text you a code to your SMS and I'm not a big fan of that.

 

I would rather the Authenticator app than the text, although my Authenticator app is

 

Yeah.

 

getting pretty darn full and I had to scroll a bit to find the right one and that's annoying.

 

Yep, agreed.

 

I wish everybody would just use Google Sign On and if Google wants to do 2FA that's fine as long as it's one 2FA, one Authenticator account. I just always use the same one. That would be nice.

 

Yeah, I'm totally against calling SMS messages to FA, especially if we're talking about if I can log into your service from my cell phone and you text the code to my cell phone, that's

 

Yeah.

 

not two FA. That's not two factors. That's all just different apps on the same factor. And then the other one is if you're offering 2FA, but you don't support things like my YubiKey here, I

 

Mm-hmm.

 

have to use the Authenticator app. That really grinds my gears.

 

I've never tried the YubiKey. I actually had one from a previous employer. I didn't know what it did and I threw it away.

 

Right? Right?

 

And I told a colleague or a friend, like, yeah, I had this, this YubiKey, I don't know, I threw it away. He's like, what, you threw it away? That's worth, I don't remember what it was. What are the costs now? I don't know.

 

They're like $100 or something,

 

Okay, yeah, it was more than that.

 

I think.

 

This is like 10 or 15 years ago. So I'm sure there were a lot more than that.

 

Yeah.

 

This was like, what?

 

Right, yeah, for sure. Well, it looked like a broken piece of plastic off of

 

Yeah, I couldn't store MP3s on it.

 

something that couldn't find where it went.

 

What can I do with it? Ha ha ha.

 

For real, yeah. Now, I'm a big fan of the YubiKey, because like you mentioned, my authenticator app, I have to scroll for days to find the one plus. I don't really consider it to be a second factor, because it's on the same factor that I'm trying to log into sometimes. And it's just easier. I just plug this in, or some of the newer UB keys do NFC, near field communications. You just hold it close to the device. And at that point, you can steal my laptop. You can steal my phone. You can crack my password. You can crack the. face recognition or whatever is installed on my phone but until you get this physical key from me I still feel like I have a little bit of control over the situation.

 

How do you feel about the passwordless authentication? Basically, your website says, welcome, click here, and we'll send you a login token that's good for 10 minutes.

 

Yeah, I'm kind of on the same fence as the SMS code. I understand what they're doing. Managing passwords is hard. Everyone does it poorly. But I don't know. In the event of a compromised device, I don't know that that counts as security. Because almost everyone, if I have access to your phone, I've probably got access to your email too.

 

Probably, yep.

 

Yeah, and I mean, there's some gray area there, because the Authenticator app I use is Authy, and it does facial recognition. So you would have to get my phone from me, then unlock my phone, then launch the Authy app, and then hold it in front of my face. So I mean, there's some layers there, but to me, it just feels like those layers are pretty thin and flexible.

 

Mm-hmm. I remember many years ago I was working on an app where we had to manage some of this stuff. Basically we were doing email quarantine for people. And we would daily or weekly send a report. You know, here's the six messages that got caught in quarantine. They're probably spam or phishing, but if one of them is legitimate, you can click here and log in. we were sending these to users who didn't have passwords on our account, on our system. Basically their administrator would set up an account and then all 500 people at the company are there. And we didn't want to connect to the LDAP or whatever and ask for their clear text passwords. That's not safe and not even possible in many cases,

 

Seems reasonable.

 

fortunately.

 

Hahaha!

 

So what do we do? So we had to come up with some sort of like passwordless authentication. So... Yeah, it was email links, you know. Each link had a, or each link in the email had a, they click on it and then they would be sent a new, an email token that was good for 10 minutes or something that they could log in with, which I think was probably the best we could do in that situation. Although in that case, we were literally talking about email. If somebody had compromised their email, all it would give them access to was their email. So, you know, it's not like we're logging

 

Hehehehehehe

 

into your bank here, but.

 

Yeah, true.

 

But still, yeah, sometimes it's hard to make those calls.

 

Yeah, all in all it is a tough problem. And then you have to compare that with the scope. What's the potential downside of getting this wrong and then make decisions accordingly. I think that's some place where we struggle sometimes.

 

And this is such an important topic that a lot of people, especially if you haven't been in this industry for more than a few years, you probably haven't thought about a lot of this stuff. But this, and that's why security is so bad on the internet because 50% of our workforce has less than five years of experience. And unless you have about 10 years of experience, you're not thinking about this stuff regularly, or you literally studied security. Most developers don't think about this until they're bitten by it, and that doesn't happen very often. So this is difficult stuff. It's complicated. I mean, this is some of the hardest stuff, especially when you get into secure encryption and stuff like that. Some of the smartest people in the world are solving these problems. But yeah, it's a hard problem and people don't think about it. But if you do think about it, you can at least start in the right direction. What's the worst that could be compromised if we forget to delete Bob's account? And what's the worst he could do?

 

Great.

 

And... Yeah, think about those things. It'll make you a better engineer and a better employee. And while on the topic of what's the worst that Bob could do if he forgets to delete his account, if you're Bob, it's also important that people delete your accounts when you leave the company, because you don't want to be, I've had this happen a few times. As soon as I discover after I've left the company, more than once I've discovered that I still had access to something I shouldn't. And as soon as, and whenever that happens, I... I contacted the company immediately and tell them I still have access. A company I left about eight years ago, six months later I powered on an old laptop and automatically logged into their instant message system.

 

Hahaha.

 

Now I don't think I could have done anything nefarious on instant message. I could have spammed some former colleagues or something. But I immediately contacted them and said, hey, I still have access to this account. Please delete it. And then it happened again. The same company I talked about with GitLab, a few months later I discovered I still had access to one of their GitLab repos. So I'm contacting them immediately, please delete my access. Because I don't want to be on the hook. If they ever discover a breach, I don't want them thinking it was me.

 

Yeah, absolutely. Even if you didn't do it,

 

Exactly.

 

the level of effort you would have to go through to prove that you didn't do it is not something that you want to spend your time and effort

 

Exactly. I mean, and you don't even want that phone call from the lawyer.

 

doing.

 

What were you doing on September 13 at 12 p.m. when our server was hacked?

 

Right?

 

You know, you don't want that call.

 

Which

 

So.

 

for me is a horrible question no matter what the date is,

 

Right.

 

because like, I'm like, I don't know what's today's date? Hahaha.

 

So yeah, I mean, the point is, you don't want that extra access either. And even if you're worried,

 

Yeah.

 

even if you're still at the company, I mean, it's also a liability. I mean, so, you know, I've worked at places where somebody was given full administrator access to AWS. And that's dangerous. Like, I don't want that access myself because I don't want to accidentally delete something and I don't wanna be accused of something if it does get deleted, you know? I don't intend to do anything wrong. It's not that I... I... excited to have extra access. Like, oh, I have backstage access now. You know, it's not an exciting thing to have too much access if you're responsible. You want the minimum access so that you can't accidentally do something or be suspect if something accidentally happens.

 

Yeah I think a good way to summarize that is one of the companies I worked at a few years ago was talking with our corporate attorney about data retention and we agreed that the data retention was like I think it was like three years or something and I said oh well we have like seven years of data and he said delete it. I said why it seems like more is better and he said no. He said anything beyond the three years that we are required to keep. becomes known as the defense exhibit A in a courtroom.

 

Mm-hmm. Yep. Yep. Exactly. Alright.

 

Cool, well should we do some picks?

 

Yeah.

 

Alright, do you got any ready?

 

I do. I have a couple.

 

Let's hear it.

 

So first, my wife and I have been watching the Rings of Power on Amazon, which is the prequel to The Lord of the Rings.

 

Oh, I've heard good things about that.

 

It's about Galadriel and Elrond and basically how the rings were created and sort of the backstory to The Lord of the Rings. So if you're a Lord of the Rings fan, you'll enjoy this. Different actors, but the same characters and really the same... sort of feel, you know, it feels like it's the same. It doesn't feel like some cheesy knockoff or something. So

 

Right on.

 

That's my first pick. My second pick is a book I just finished reading by James Kars, C-A-R-S-E. It's called Finite and Infinite Games. Now some of you listening may be more familiar with Simon Sinek's take on this concept, The Infinite Game, and he has a talk on, you can find on YouTube about the same topic, but I can't stand that bastard. So I didn't read his book.

 

リキリww

 

I went to the original source. So James Kars is the one who came up with the concept and Simon Sinek, I don't want to say plagiarized because I'm sure he didn't, but he took the concept and sort of made it, gave it its own twist. But the concept is finite games are games that have rules like baseball or poker or something, right? And there's a winner at the end.

 

Mm-hmm.

 

And the purpose of the game is to win. And then there are infinite games where the purpose of the game is to keep playing. And you might think of open world games like Skyrim or something, but that's not it. Skyrim is still a finite game. I mean, it doesn't perfectly fit the definition of finite in the terms of the book, but within the game, there's still goals and you maybe don't win the game, but the truly infinite game is, I mean, life, basically.

 

Yeah.

 

And he really goes, it's sort of a philosophical book and sort of a, yeah, I don't know, that's probably the best way to describe it. Talks about how this applies to business, to life, to family life, to sexuality, to war, to slavery. So he goes into all sorts of topics. It's a little bit of a, I don't want to say dense read, but like it's deep. So it's something you need. You don't just listen to it lightly on, you know, if you really want to get the most out of it, you're gonna either listen to it, but you can read it. You really want the time to think about what you're reading. So I do recommend it. Finite and Infinite Games by James Kars. Nice, interesting look on life.

 

right on cool I like that we should post that over on the red forum see if anyone else has read it For my picks, I've got two as well. The first one, I'm gonna pick Asana, the project management system, asana.com. And so I've used, I think I've used every project management system ever made. And never really been successful with any of them. And I may not be successful with Asana, but I'm pretty positive at this point a couple weeks into it. So one of the cool things that they have that I really like is this workflow builder that allows you to say, when this thing happens, create these tasks, or close these tasks, or move this task to this stage, or whatever, which is pretty common in other project management tools. But this one just feels pretty intuitive. And Just to give you a specific example, creating videos for my YouTube channel, hashtag shameless self-promotion DevOps for developers, is a pretty labor intensive process. I come up with the idea, then I script out the video, then I record it, then it goes over to the editor who edits it. And then I check the edits and then create the description. It goes up on YouTube. and break it apart into shorts to do YouTube shorts and Twitter and Instagram and all the different social media posts that go around that and then I try to do I've been trying to add it to my website as well as a text based version but all of these different steps or whatever you know I have a hard time tracking those so I built it out into one workflow in Asana. So the minute I drag it from an idea over to scripting, it's... starts this workflow and whenever I mark the scripting is complete it triggers the next task and then whenever it's ready for edit it goes to the edit status automatically and that sends a notification to my editor with a link to Dropbox where the raw files are and so it's been pretty cool. So if you're looking for a project management tool check out Asana I've been pretty happy with it. And then My other pick for the day, Jonathan, you get to see it. Listeners of the podcast, you don't get to see it, but I will describe it well. This is my BearMax massage gun. And this thing, I'm not going to lie. If my house were on fire and I had to choose between rescuing this and my wife, I'm not sure I would make the right decision.

 

Wow.

 

This thing is great. So I signed up for a 100k run that I'm going to do in February so I've amped up the number of miles I'm running each week and this thing is just so cool. It's just a little massage gun but you just put it on the muscle and set it the speed that you want it and yeah it's really nice.

 

Wow, when you showed that to me, I was about to say, this is supposed to be a family friendly show, Will. I don't know if you can talk about that here, but.

 

Straight up!

 

Ha ha ha ha ha.

 

Like,

 

But it's just a massage gun, guys.

 

my god, what? Right?

 

It's all right. No problem.

 

It's horrible. It's funny but it's horrible.

 

Alright.

 

Cool. Yeah. So on that note.

 

I have already posted the book on the new Reddit group. So by the time you hear this episode, it's there. Don't be late, don't miss out. This is your FOMO moment. Go check out the new Reddit group and comment about whatever you think is cool about teachers and DevOps.

 

Yeah, for sure, because it's one topic that keeps coming up over and over in the parts of this podcast that you all don't hear. We're curious about what you all think, what's on your mind, and want to engage with you more to make this closer to a two-way conversation. So we're trying out the Reddit group to see if that works. So

 

And if you hate Reddit, go to Reddit and tell us about it, and maybe we'll consider changing to something else.

 

give it a shot, and then we'll see you all next week.

 

Just an experiment.

 

Yeah, absolutely. That's the cool thing about Reddit is you can upvote and downvote.

 

Uh huh, right.

 

Ha ha.

 

Great. Well, it's been an adventure.

 

It has.

 

Look forward to next week.

 

All right. We'll see you.

 

Cheers.