 Hi, I am Tiffany Jernigan. I am a developer advocate at VMware. You can ask me what that means if you don't know afterward. But includes doing stuff like this. So yeah. I have my Twitter up on there on further slides. There's also my mastodon, which I wish it was shorter, but it's the whole thing, but it's there. So yeah, I'm going to be talking about getting started with Kubernetes users and permissions without just using cluster admin. Come on. I tried to. There we go. All right, so we have two different types of auth. There's authentication or authend, which is who are you. So it could be any one of you people. It could be a robot or whatnot. And then there is authorization or authsy, and that is what are you allowed to do. For instance, you could be like, hey, you, Bob, are allowed to be at this conference and attend someone's talk. But no, you're not allowed to throw food at the speaker or something like that. All right, so first we're going to talk about authent and provisioning users. So Kubernetes is very flexible here. You can use TLS certs, maybe with your own CA or not. But since the Kubernetes API server doesn't support revocation, you should definitely use short-lived certs. Don't have ones that are like, here, I'm going to have this last for like five years and crash your fingers and hope nobody else gets access to that. Instead of trying to do something maybe that, like, you get a new one every hour or something like that. You could also use OIDC tokens with any OIDC provider. Something like in-house, for instance, like Dex or KeyClug or SAS, like Octa. And then that, in turn, can plug into your cloud's IAM. For example, you can map your cloud provider users to your Kubernetes users. You can also deal with service accounts to provision users as well. So as a little fun note in Kubernetes, you don't really create a user. You give, for example, create pods permissions to, say, Bob. And as long as someone shows up with a valid search or an OIDC token for Bob, then they can create pods. So there's two main things that interact with Kubernetes that are either humans, which, as far as I'm aware, is probably all of you. And then there's robots, I don't know. We'll see. So for humans, you can do things with like TLS, OIDC, service accounts, et cetera, with robots that's basically usually used with service accounts. So starting off with certificates. So the commands here show you how to create a certificate signing request. You might see that listed as CSR in short in a lot of places. This example is using open SSL because it's super widespread and you probably have it on your machine by default. I'm using a Mac, and it was already there. I didn't have to download anything. Many folks, though, might prefer using something like CFSSL, which is Cloud Flayers, or maybe they want to use Vault or some other certificate authority. And that's usually shortened to a CA. And then after that, you then transfer the CSR to the CA. And depending on what kind of cluster you have, this can be done differently. So for example, if you are using a self-hosted cluster, or you're using like QBADM, basically, where you have access to the nodes of the control plane. And if you want to do some experimentation, here is a specific example that you could be using. This example assumes that we have a cluster deployed with QBADM for this one, and that the CA keys live specifically in Etsy Kubernetes PKI on the control plane. And then, for instance, the 1, 2, 3, 4, you could have as something actually meaningful to you. So another method with certificates is going through the CSR API. So this is what if you want to deal with certificates, this is the route you'd have to go down if you're using a managed cluster since you can't actually get, again, inside of the control plane on a managed cluster. Like this one works for managed and self-hosted, basically. So the CSR API is in the Kubernetes API, so you can get certificates from it. It basically makes Kubernetes act as a CA. And this is what you would apply with Kube-Cuttle. It might be a little hard to read back there. There's a bunch of lines, but basically what it's doing is it's giving you the request, which is that file, the CSR file that had been dumped out from OpenSSL previously, and it uses that. So this whole part, dealing with the CSR API, you're interacting with Kubernetes with Kube-Cuttle. So after you create the CSR, then you need to actually go and approve it. So you could do Kube-Cuttle, certificate, approve, and then my thing is user equals a lovelace. The user equals is just so that it's not required. You could just have it a lovelace or whatever you wanted there. It's just so like if you were searching and you wanted to go based on what you're defining as a user, you could see all the people are like that. And then what you would need to do is to retrieve the certificate. So then you just do a get on the CSR. You'd get the, and then you would do a base 64 to code on user.drt. And then you give that file back to the user. So once you actually have that, then you can pass in your key and the CRT file over to a Kube-Cuttle config, which is basically adding the certificate and the key to your Kube config file. All right, so now certificates are out of the way for a bit. So the other, one of the other things is tokens. So if you have a conceptual understanding of TLS, then you probably have one for OIDC as well. Things are different depending whether you're using a self-hosted cluster or if you're not. And if you are, there's two flags up there that you need to add. So one for the OIDC issuer URL and one for the OIDC client ID. On managed clusters, you want to use the OIDC with the provider. Basically there is often like a quasi-parent integration with IAM and generally that is with using OIDC under the hood. And it will then automatically be using IAM or something else and just like do that for you. There's links that tell you a little bit more about it. Like one is like it's specific for EKS, but obviously there should be guides for all the other ones as well. There's just kind of limited space on this slide. So I just picked one. So and then if you're not using a cluster like that, then if you are say already using something like vault inserts or you're just like truly invested in certs already, you probably still want to just keep using TLS certs versus starting and trying to figure out everything with tokens with OIDC. And if you're not already using TLS certs, you may not want to get started there just for that at that point. Service accounts are typically used for say like processes, programs, services that are running autonomously on a cluster, but nothing's gonna stop us from using them to manage access and permissions for users. Even if that's not really what they were meant for in the first place, but you can do it. So for the demo I'll be doing, I'll be using them for demo purses and you can too. If you don't like want to go the right way through like setting up a bunch of hoops to actually deal with setting up TLS certificates or OIDC based authentication. So like if you're, especially when you're just trying to start and figure stuff out in the beginning, it's a really good way to go about it. So a service account is, yeah, it's just a user with some funny looking name thing there. It's like system service account and then whatever name space that you were in and then the name of the service account. So then there's, since we're talking about tokens in this space, so there's also service account tokens. They are JSON web tokens or JOTs, like OIDC tokens, but they are generated by the Kubernetes control plane. Specifically, it's a controller and the controller manager. And by default, Kubernetes will, like in your container pod, Kubernetes will automatically place a token in a file specifically under that location, which we'll actually take a look at during the demo. And that token is a token for the service account of the pod that that container belongs to. Enough about that type of auth. Now let's go to the other type of auth. So we're gonna look at Ozzie and specifically role-based access control or RBAC for short. If you hadn't noticed, there's a lot of acronyms. They love acronyms. So a high-level idea of it on Kubernetes is that first you define a role or a cluster role. So like a role would be specific to a namespace, a cluster role would be well for your cluster. And that is a collection of permissions, like things that can be done. So things like listing pods, creating deployments, setting the scaling for like a specific deployment and a bunch of other things. After you create that role or cluster role, then you would, like it exists, but it doesn't actually do anything. So you need to be able to bind that role or cluster role to say like a user or a group or a service account with using a role binding or a cluster role binding. If you're wondering, oh hey, what can I actually do? So say my resource is a pod. What can I do with a pod? Like how do I see whether I can do a get or a list or a watch or a patch or whatever those things are? You can actually find that out using kubectl and it'll basically spit out a thing of what you can actually do with it. And you can, depending on like where the group is, like maybe it's in V1, maybe it's not. If you're wondering, hey, where is it located? You could just do kubectl space api-resources and figure out where it's located. So this is the default service account that gets created for whatever namespace you are creating. So this is CNSC because that's a short abbreviation for this conference. And then it just creates a default one. Then here is an example role for getting pods. So you can see like in resource you have pods and then the verbs are get and list. So the reasoning of both is say if you were like I have an nginx pod, if I have just get I could do kubectl get pod nginx. If I try doing kubectl get pods, it doesn't, it can't do that, it needs a list. And then you need to have the role binding. So you can see that this basically has the role that get pods role and then it has the service account which is the one that I've been talking about. There's also fun stuff with auditing and of course I noticed that I hadn't fixed this before we got in here and I didn't fix it now. The first line is supposed to say kubectl op space canine dash dash list, I'll fix that later. But and then there's a bunch of other tools that aren't specifically built in that you can get like plugins for. All right, so demo time. I fixed that. There we go, pretend that never happened. I clear it and then it just comes right back. All right, so first let's make sure that I did delete the namespace. So if we get namespaces, all right, cool. So there's just a bunch of the initial stuff. So if I do a create, create namespace of like cloud name, security, gone. So there's this really cool tool called kubenes that I'm at Albincon created that makes it so that you can switch between namespaces that you're currently in. So you don't have to do the dash end and then give it the namespace every time which can be really annoying. So if I do a kubenes and then that. So now I am in that one. So if actually if I just run kubenes you can see that I'm specifically in there. All right, so I'm just gonna create some deployments. We will see why in a bit. How's the internet, everybody? All right, so I'm just, they're both using Nginx because they are, they spin up. I don't have to do anything weird to make sure that it stays running and whatnot. All right, so if I did a kubenes, oh yeah, and I can't remember where to mention this. The k is me being lazy and aliasing kubectl to k because I don't wanna type that. I already like my tab completion and everything else. So all right, if we do a kget pods you can see the two that are running there right now. So like basically however my cluster is set up I have an effect like cluster admin permissions. I can, if I wanted I can go and delete these. I can scale the deployments there or there, all that fun stuff. How about what if we go inside of a pod? So if I do, oh my gosh. Okay, so there's this cool thing called nixory.dev. It basically ends up giving you a container image that has these things that you list with slashes installed in it already. So like shell, kubectl, curl, jq. It's just really handy. And it was nicer to me when I demo run this. All right, so now if we try to do a kubectl. So I'm on the same cluster but now it's throwing up and saying I can't do this. So like it might be hard to read because of how it's wrapping it. But basically it's saying that weird name my user like with my namespace of CNSC and default which is again the default essay that gets created. I don't have the ability to list like pods in this namespace. So basically we need to fix that. So we can do that by creating a role and a role binding. So right now we don't have to create a service account because well, I'm just gonna use the default one. So if I do k create role. All right, so this thing, I'm just calling it get pods. Verb is just whatever type of action you're gonna be doing. So I wanna be able to do a get and I wanna be able to do a list and I want it specifically for the pods resource. So I created that if you wanna take a look at it we can see basically the API groups, the resources, our pods and that I wanna be able to do a get and a list. So then now, so we have the essay, we have the role. Now we actually need to do a bind them together. So if I create role binding. So this one you give it the role and then you give it that service account. So that's the name of the service account that we have right now. So now if I do a kubectl get pods I can actually see them. Okay, so that's cool. So now let's, has anyone tried using like dash v6 or like up to the verbosity on a kubectl command before? All right, see two people. All right, so if we did the get pods again if we do dash like v6 you can actually see what address is being used for these requests. So if I go and copy this, I could go and try doing a curl. I'm gonna do dash hk which is technically dash dash insecure because like I know this is my cluster. I trust it. This is a demo. I don't really like not worried that whatever the API is giving back to me is like garbage or some crazy stuff for now. So if I do dash k and then I give it the URL there. So okay, now it's failing. So like what's going on here? I just did a kubectl command to get pods. I have my role binding and everything but it's telling me I can't do it. If you specifically look there it says that you are system anonymous. It's because it doesn't actually know who you are. So in order to fix that you need to actually give it the service account token. So and remember that this right side is within a pod that's in this cluster. If we look in this one location we can see this lovely token. Looking at this you're just like okay it's a bunch of gibberish like I guess that's your token. If we go and copy this slide the correct direction there we go. If you go to JWT.io you can actually dump it your encoded stuff in there and dump it out and actually mean something. So I'm not sure if it's really legible. So basically you can see I'm using a GKE cluster. You can see the namespace is the NSD tester is that pod that I am currently in. And then my default service account and you can see all that there. Cool so we have that great. So now what we do with our new with our curl is now we give it a header. So authorization bearer always can do this wrong. Okay I need to save my token. So I can just call it like this. On laptop I have faith in you. Sometimes no faith. Fine be that way. What did you say I did? Okay token. Yeah so back to what I was saying is we end up so we do if we do the curl give it dash H, authorization token. I did, off row. This is why people shouldn't let me type. All right so if I pass that into JQ and gave it the items.metadata.name. Man this is so slow. Yeah so there you can see the pods that we had before. Okay so with the whole dash K thing let's get rid of that now. If we look in this same folder. Oh my goodness. Hello. Okay wow, all right. You can see here that there's a CA CRT file in here so instead of this lovely dash K we do CA cert that it still works. Okay so as one of the more recent versions of Kubernetes service account tokens are bound by default. So let me show you what that means. So this token basically is bound to that pod. So if I were to go over here basically I'm creating another pod just like the other one and so if I were to go and just make token equals to that same thing. Oh not that. And if I go and copy this exact command you can see that I can still run it, right? So now what happens if I decide that I don't want this pod anymore? Depending on how slow my internet is this might take a million years to go away. But yeah so that wasn't a thing before. I think I can't remember specifically it may have been 1.21 but you'll need to verify that. Depending, okay wait, let's see, it's gone. All right so now if I were to try doing that again I now got unauthorized because that token was bound to that pod and it now it has vomited and no longer works. Okay so that's just like that basic stuff of that. So and since everything's going slowly I'm gonna see what I can quickly get through in the next I believe I have 10 minutes because technology, it loves you and it hates you. All right so we were using a default service token so now let's go and create one. So if I create a say so I can call it scalar. Basically what I'm gonna do is create something that I can go and scale a deployment. So there's some built in cluster role and cluster role bindings for instance like there's like if you did a, I'll just do it K get cluster role maybe I shouldn't try doing a thing like that and getting a grip but there's a thing that you have that is called view. So I could do K create cluster role binding I can give it that cluster role that already exists which lets me view a bunch of stuff and do nothing else. It's basically read permissions and give it to my service account. Okay so if you are specifically dealing with if you're trying to create a pod with a specific service account since this one isn't the default one anymore there used to be a way to do dash dash service account I don't know why it got removed I wish it didn't so now you have to actually do with overrides which is special so yay Jason. So then I give it that I swear it's way faster an hour ago. Hope everyone's first day of this conference is going well. Um yay okay so if we do a oh my goodness hello letters I guess worst case if this actually fails I can walk you through what actually happens because I threw all this stuff into my slides too. No my goodness I feel like I've gone back to the early 2000s okay well that's there we go. So get all doesn't actually do get all but it gets a bunch of stuff so my view is letting me see all of that stuff. I'm not gonna try typing and if I were to try deleting stuff right now it would fail I'm not going to try that because I'm just gonna fail. So what I want is to be able to create a deploy way to scale so I could create a role so I can call that scaler because I'm lazy so when you're messing with something like replicas you which or like scaling you would do a patch so it gets the resource of deployment slash scale and then I want to do it only on the nginx one because you remember of nginx and I have web. So I create that I guess well it's doing that if I do a keep that all scale deploy except for the problem is I have typing issues so all right scale nginx replicas equals two yay internet. Well eventually happen if I run that right now it's gonna vomit because I don't have the permissions to do it oh wow unable to connect to the server. Yay internet there we go okay. Your hand if you had a demo be this painful at a conference sweet thanks for commiserating. Okay so if I try doing right now it says that I can't patch deployment slash scale in there so if I go and create that role binding now I can scale that and if I were to try scaling web it fails because I specifically named the resource. Okay so now we okay we have that but right now I'm using like view that means I can see everything what if I only want to be able to just get that specific deployment so what I would want to do is first delete that cluster role binding if I were to try scaling this back down one I can't because like in order to be able to actually do anything that I have to first be able to see it I can't actually get it so what we could do is we could do an edit on the role that we have called scalar I can use my really terrible VMs VIM skills copy this paste it change that to just deployments and get so now theoretically I can scale that but so if I did a cube cut all get like say if I tried to get all again I can't do that if I did a cube cut all get deployments can't do that if I want to do engine X I can and I can scale that and that's basically all that I can do with that. Let's see yeah so I think that's everything for that part and if you just wanted to see what would happen if you did the raw it's kind of like throwing out the shows bunched up but like say what for instance services last proxy you can see what the verbs are that you can actually go and use and then also now that I have these permissions if I do a cube cut all you can do what you can do a can I and then like do a specific thing there is also eventually a way to do dash dash list maybe if you hit enter more than once I'll make it work yeah there we go okay so you can see down so there's a bunch of stuff that is here by default that you will normally see like the ones up here API is et cetera but the ones that I these ones here are specifically there because I added them with my role and my role binding okay if we go back over here yeah demo that just happened it's kind of janky I will try making it look better when I actually posted but I thought it would be useful because a lot of times people post here's my code for my slides and then they put the word demo and then it's like well if that you don't say you don't have a video or you don't like watching videos okay where's the demo so I attempted last night to do this so basically it goes through every single thing that I did today hopefully there's nothing I think I have comments and stuff in there too but yeah it's just basically all things with the default namespace service count bound service count tokens creating new essay like factory roles so like using that cluster role that's already there as you noticed even in my demo I did not give cluster admin permissions don't do that and scaler and yeah it's just a bunch of slides of that this is so I learned through Bernard's talk that apparently you can actually there's actually a way to like put a review on the SCED app didn't know that I don't know how many people actually are logged in and it only has smiley face sad face or a line so you don't have to log in so here's a little link thing I would super appreciate if you could give me some feedback because I would like this is my second ever security talk and I want to improve on what I'm doing so yeah thank you everybody