Kubernetes Security - Pod Security Standards | How to use them to enforce security contexts

let's dig a little bit deeper into [Music] Security in this video we're going to be covering pod security standards and pod security admission they go hand inand with one another which is why we're covering them in this video together at the same time so the standards are just a set of standards for for pods and their security contacts or containers and their security contacts and the admission is a way of applying them to all those pods and ensuring that all pods follow the rules of it we do it at the namespace level so all pods within a namespace will have standards applied well not a standards applied you still have to write the security context for them but it enforces or allows them to go through with audit logs or Warnings displayed to the user those standards and the reason this is all important is because of two reasons actually actually because of security security is very important and should always be very important and should never go to the bottom of the list it is the main reason people get hacked they don't focus on security they focus on minimum viable products and things like that and you know it just if you don't get security in you're going to get hacked if you don't get hacked you've been very lucky that's pretty much all it comes down to so security security security always security make sure it's done and sure is in there from the start security by Design that's what you need to do secondly now I've kind of drilled that in it's actually part of the exam if you want to go for the certified CU bonetes security specialist exam then this will come into it at some point or at least it will likely come into it at some point so that's why it's important to know now I feel like I've rumbled on a little bit in this intro so maybe we should just get into it so before we get into a quick example I'm just going to run through a bit of the docs just so we can give you an overview of what's going on here so pod security standards there are three kinds these are cumulative and range from highly permissive to highly restrictive and they are privileged Baseline and restricted so we start with privileged this is basically just as it is in the cluster by default it's unrestricted it provides the widest possible of permissions and it's just yeah it just allows for privilege escalations the next one is Baseline which is minimally restrictive meaning that if you were to run a default pod with no security context then it would work if you then started applying some security context in then there would be certain rules you have to follow which are detailed below restricted is heavily restricted even the basic deployments of a pod wouldn't work it would expect you to set some defaults so let's go through some of those and see what there is I'm going to scroll past these bits cuz it pretty much explains what I've just said in a little bit more detail but if you want have a read of that obviously go ahead now we have things like controls we have restricted fields and then the allowed values for those restricted fields which are the policy so for example in this one we have the control which is host process and the policy the policy is saying that if you set security context. Windows options. host process either at the Pod level the container level init container ephemeral containers any of those things if any of those have a security context of Windows options and host process it must be set to false or just undefined if you have a security context of host Network host P ID host IPC then again it must be set to false or undefined and it's the same with all of these you can see how all of them would be defined and what their values are for example take capabilities if we look at this one we looked at capabilities in the last video as part of the security context video and we can add these particular ones that's absolutely fine we're allowed to do that we'll see later on that this goes further down and we actually override that a little bit further by only allowing the net buy service when we talk about the restrictive policy and I'm not going to read all of these out to you because obviously you can you can read through the yourself to see what applies where but you can see that we've got a bunch of different ones of restricted fields and allowed values for those fields so as long as you're following these rules you will meet the policy you'll be absolutely fine if we take a look at the restricted like I say it takes everything from the Baseline profile and adds some additional stuff or overrides something so if we take a look uh for example the capabilities here we can see that we have to drop all capabilities and we are allowed to add the netb service that is it there's no other ones the you know if if we try and add one of the ones from mop here then it won't work the only one that will is a netb service so restrictive is restricting it even further for one of a better description of that and that's pretty much all the standards are there are a bunch of standards that are there to help secure your pods and containers to make sure you are following the best practices so how do we apply these well if we look at the Pod security admission which is part of the Pod security admission controller we have a way of enforcing them so we have three levels and and we just add labels to namespace and those labels will be a mode and a level your levels can be enforce audit or warn enforce being that it will reject any pods that violate the policy audit will be that it will allow the Pod but log it in the audit log and warn is that it will allow the Pod but it will display a onscreen prompt to the user saying hey look you've violated these policies in my opinion we should all be running in force on Baseline and then audit and War on restrictive so that people know that they can restrict these further to be even more secure but the Baseline should be the standard in my opinion doesn't make me right of course there are going to be scenarios where the Baseline is just a little bit too restrictive and it's down to the people to put security contacts in that match their requirements but on a basic level I would say everyone should be using Baseline within force and then auditing and warning for restricted again just my opinion anyway little diversion there let's talk about how we implement it and what we do is we add labels to a namespace like say with modes and levels the mode being enforc audit or Warn and the level being privileged baseline or restricted so that's how we apply a standard we then need to give it a version so the version can be latest but it should probably be the cluster version that you're running on so it's usually the minor version which would be 128 in our case and again what we do is we set the mode so enforce auditor one hyphen version equal to a version and that's all it is now that might not make a lot of sense at the moment and if it doesn't we can click this link here which takes us over to this page here that tells us how to implement them I've just copied and pasted this into a yaml file so I've just kind of preconfigured this ready for us and I'm going to jump over to the idea now and we'll take a look at it so over on the IDE we have that yaml file um all that's happening here is that we are enforcing Baseline with the version of 128 we could have this as latest if we wanted to we are auditing so audit logging but allowing restricted profile so anything that violates the restricted policy will be allowed but we'll log it in the audit log and then anything that violates restrict a policy will be warned to the user on screen all of them are using version 1.28 because that's the cluster version we're on and it just makes sense to keep it with the version we're working with and for this I'm creating a new namespace called security hyen learning so how does this work what can we do to test this out and make sure it works well firstly let's apply the name space so I'll do qtl apply hyphen f and then we will do workload and then we're in a new folder called security here and it's nsy security I also have web and CM these are direct copies from cm and web in here nothing's changed the only thing that has is that I'm targeting the new namespace that's it there's no security contacts or anything like that on any of these containers or the Pod itself so let's let's apply that and see what happens first we'll do Cube CTL apply hyphen f and I'll do workload security so we we're applying the config map and the web resource here as well as everything in the namespace again which won't change and there we go straight away we've got a warning so this will have been logged in the audit log two and what it's saying is look you're going to violate the Pod security standard of restricted version 128 and these are the violations of that it doesn't violate any Baseline ones because Baseline is like I say if I run that as just Baseline it will get deployed and the evidence of that is if we get the pod you can see all of those pods are running because it meets the Baseline standards but it just makes sure that we're not doing stuff we shouldn't be doing so for example let's in fact let's just have a look at one of those policies again if I jump back up to Baseline and look at something that we are not allowed to do so privileged containers let's do that so I'm just going to run uh let's have a look we will go security context and we'll do privileged and we'll set that to true what I'll do is I'll go ahead and delete that deployment now so if I just go for delete and then we'll do web and then I'll reapply it remember we want the Baseline standards and the Baseline will not allow us to run it as privileged so I'll apply that qctl get pod I'll reverse search for the get pods but let's just have a quick look at this so would violate pod security restricted and we've got this privilege true engine X must not set this to true now this is saying it's the restricted one but it also applies to the Baseline which we've just seen so let's get the Pod and have a look and we can see there's no pods in the namespace at all the reason being because it's not allowed to deploy like I say this only applies to the Pod level not the deployment or the replica set so if I do QBE CTL get deploy and rs we'll see that we've got them there's desired three but current none so let's take a look at the replica set and we'll do qctl describe RS repli set names space security learning and see what happens there and straight away bang There It Is look it's violating pod security so great that's violating the Baseline one it's not allowed to deploy the deployment and rep that's there but we're not allowed to deploy it because it violates it so we're going to delete that that's fine let's go look at some of the other ones to make sure that we're not violating anything else as well well we know we're not they're all restricted and they're only warning go and putting audits out but as a good engineer I want to make sure that these are as secure as I can make them okay so let's have a look at what we've got here we've got a container of engine X set to privilege true well we've just removed that so we're okay there we've also got this allow privilege escalation not equal to false so if we have a look we've got containers engine X and engine X Prometheus so that's this one and this one and they must set the security context do allow privilege escalation to false that's simple we can do that we can do allow privileg escalation to false I can copy that and drop that into here now it's worth noting here that it says containers not pods we can only set this one at the container level let's look at the next one we have unrestricted capabilities again at the container level which is capabilities. drop equals all well let's do that we can do capabilities we can do drop and all we'll drop that into here as well for the engine X container so that's the engine X and engine X Prometheus containers covered and then we've got this Runners non route not equal to true now this is POD or containers well let's set that at the Pod level then so we'll do security context we'll do run as nonroot and set that to true so that will cover that one so that's the engine X and engine X Prometheus containers covered because we've done it at the Pod level and then finally we've got this setcom profile now I've not covered this before don't worry too much about it for now we will cover it more in a later video but we'll set this to runtime default so we need set comp profile. type at the Pod or container level so we'll do it up here and then type equals run time default and that should get rid of all of the warnings so we'll go ahead now and apply that so let's do that and Brilliant there we go so I'm just going to make sure that's everything up to date no warnings everything's great we can go home go back to bed do whatever we want to do it's absolutely fine right not necessarily let's take a look at those pods problem is engine X loves running as route and there's not really a lot we can do about that and if we take a look at this we'll do qctl describe pod in the namespace security learning and there's an error container has run as nonroot and image will run as root that's just the way the engine X container is released but they do provide an unprivileged container to get around it if you want to but that exists that's there so you know make of that what you will anyway so how can we fix this well we can just run as non rout for the engine X Prometheus one right and that's that's fine so we can just take that delete it out of the Pod level drop it into the security context for the container engine X Prometheus reapply it and then we have this error come back up but we as the administrators go y we know why that is it's fine we're allowing that through it's only a warning it's getting logged in the audit logs but we're allowing it through it's fine so let's take a look at our pod again oh no now we have another error what could this be well this is a crash loop back off so we're going to check the logs for this one I mean we could describe it you know but we're not going to get anything from it so there you go it's just backing off for some reason or another so let's go ahead and take a look at why that might be so we'll do logs h F and let's take a look ah operation not permitted H it's trying to Chone something here wow I know for a fact that that would be this capability causing that problem so we're dropping all but we need to allow or add Chone which is one of the permissions allowed at the Baseline level if we go back take a look at some of the capabilities we can see here we've got Chone so that should fix that but at the restricted level we're not allowed Chone so we need to make a decision here do we want to run this as a root container with the privilege added you know if I apply that we're going to get the capabilities we must not include Chone okay and if we get our pods has that fixed the problem well yeah it has they're running now as non route and they've got Chone but we don't really want that do we we want to be best practices as much as we can so actually what I'm going to do is I'm going to get rid of that and I'll take this and put it back at the Pod level and reapply it problem with this is it's just not going to work is it because you know if we look it's yeah okay that's fine but we already know that's not going to work because it wants to run his route and it wants to have Chone so how do we get around that thankfully this is where engine X have done something good for us and if we look at engine X Inc slin X hyphen unprivileged this is a container they've created which runs as unprivileged I think it runs on Port 880 by default so we could change that but we're already using Port 808 on this pod or it's listen on Port 8 yeah okay so we can change this to at81 for example again at the service level we can route through port 803 to 8081 it's not a problem but now we can drop those capabilities we can run on an unprivileged Port which means thumbs up everything's good right so I'm just going to go ahead and do that so we've not got any warnings and if I get my pod that's everything up and running so now we've got engine X running unprivileged not running as rout excellent that's that's Happy Days now this isn't going to be an option with every container you come across that every image that you come across you might have to build your own in which case build your own not a problem but in in some cases they've thought about this and they've put this out ready for you so this is provided by enginex but yeah that's that's basically it you know that's that's how we can restrict things that's how we can make things work for us based on the restricted and Baseline profiles the more secure the better right that's the way you got to look at this so that's why we'll leave it and that's it it's everything you need to know about the Pod security standards and the admission controller and that is pretty much everything other than reading through the standards themselves and ensuring you're following the rules of them or just getting war is out and following what it says there as I showed you that's pretty much it so in the next video we're going to talk about app armor and how that can be used in kubernetes I'm not going to touch on SE Linux I've decided it's if you're using SE Linux then you should know how SE Linux labeling applies and you can extrapolate that into security context and SE Linux within it I don't have a cluster running gy Linux and I wasn't going to set one up anytime soon maybe at some point in the future I will but to be honest you can extrapolate what we've learned about security context and if you know enough about SE Linux labeling then you can apply that se Linux Linux isn't a kubernetes things it's a Linux thing specifically red hat implementations if I remember rightly it's been a while and yeah that's that's something you can extrapolate but we're going to talk about app arm in the next one so that's what we're going to focus on and then after that I think I've got 1 two 3 four five six seven eight videos left I'm trying to make it till the end of the year at least for this series so we'll see we've got termination handlers and Messengers we've got probes we've got admission controllers which I want to touch on I'm not going to be writing one I'm just going to show you how they work how they can block things uh oidc or which is something I want to touch on because that is a good way of having users come into the cluster I did one a while back on well a few videos back on how to set up users and groups I want to extrapolate that into the oidc off now then we're going to talk about Gateway API that's just going to be a chatty video more than anything might do a few examples it's still in development so it's a bit hard to do a full video on it at the moment and to be honest I've not played with it that much yet I've only had a little bit of exposure to it so I need to come up with some content for that video then we'll have a look at things like monitoring the cluster with Prometheus and displaying metrics in graphs with grafana and maybe we'll talk about cluster API and things like maybe even service measures I might do one on sdo at some point but I feel like that might be a series of its own so I'm still deciding on whether to do that and then that is the end of my list I wrote this at the start of the year and I'm kind of at the bottom of it so it's a case of then coming up with some stuff like like how we go about cicd in a cluster you know maybe we talk about Argo flocks things like that but that's going to be a separate Series so we we're coming to the back end of this kubernetes series now I think I might come up with other ideas we'll see but so far I feel like we're starting to hit that point where I might make it till the end of year and then come up with a new series so we'll see anyway I'm rambling on a bit about stuff that I don't need to Ramble On In the End of This video so I'm going to stop and I'll see you in the next [Music] one [Music] n

Channel: Drewbernetes

Views: 519

Keywords: Linux, Kubernetes, CKA, CKAD, CKS, KubeADM, Security, Security Context, Pod Security Standards, Pod Security Admission

Id: V9o1l82Hrw4

Length: 17min 9sec (1029 seconds)

Published: Sun Oct 01 2023