Implementing the Principle of Least Privilege in Amazon EKS with Service Accounts and IAM Roles

hello and welcome to a new edition uh so in this episode we are going to look at how to provision eks uh or for that matter kubernetes to use the principle of least privilege right so especially when it comes to deploying PS on kubernetes so what exactly is the principle of leas privilege so the principal states that any application that's deployed should have just about the bare minimum access to a services that it needs to do its job nothing more nothing less so what this means is that if you have a part that needs access to S3 that's only access it should have it should not have any other access it should not be able to access Secrets manager or any other aw services or if a pod is actually have much more fine gred access wherein let's say the Pod only needs to read from S3 in which case the Pod cannot write to three right so how do you use uh the facilities that are available in EK in AWS to provision Parts with with the principle of least privilege right so in this episode we are going to look at the usage of IM am rules and service accounts to uh to bring up parts that are going to have uh this principle bigged into them the principle of least privilege where in the pods will come up with just about the bare minimum privilege they need to do their job that's it right so the the description section of this uh uh video is going to have links to some code and so on so please uh look at that and also feel free to post your questions uh uh in the comment section uh this is not the only way to do this this is one of the more uh established ways to do it uh using IM am roles and service accounts but there are other ways as well so in subse videos we are going to look at various other ways to actually you know implement the principle of lease privilege when it comes to kubernetes right so in this episode we'll but we are going to just focus on IM roles and service accounts uh to accomplish the principle of least prage okay so let's look at uh this diagram over here so we have this eeks cluster for the sake of this uh demo let's assume that it has one worker node on which two pods are deployed they're up and running this part A and Part B the requirement here is that pod a is only supposed to read from S3 and pod B can both read and write to S3 so to accomplish something like this in eks the first thing that needs to happen is an oidc provider has to be enabled for that particular cluster right so this is the first thing that needs to be done there are CLI commands that you can execute against uh uh the cluster uh to enable the IDC provider and uh I will have those those links in the description section of this video now the next step is to create a role that basically is going to be used by pod a to kind of read from S3 so a role will be created this is a regular IM role that has the Privileges or the policy to read from S3 okay so this is the next step then we'll also create a secondary rule for Part B to use and this rule will both read and write from S3 all right additionally each one of these rules should establish a trust with the oidc provider so they should be the IDC provider on the trust tab of the IM role right so this should be the trust entity okay so it's the same with rule B the trust has to be established with the IDC provider so the IDC provider is the uh trusted principal for the IM role now the next step is the creation of service tokens all right uh service accounts rather sorry service account so you first need to create a service account for pod a that's going to be associated with pod a and this service account is going to annotate this role over here okay similarly a service account will be created for Part B and that service account will annotate or refer to this particular role over here that will enable uh this part B to read and write from S3 now of course these are for the sake of uh this uh you know demo they are all in the same name space and uh we will if that's all we need to do to uh to basically ensure that part A has a token that's mounted onto it that can only enable it to read from S three and Part B has a short lived token that's mounted on Part B uh that will let uh Part B read and write uh from S3 so for the demo what we are going to do is we are first going to build uh the image uh for part A and Part B which is pretty much going to be the same image this image will have the aw CLI um um uh you know uh utility installed which will let us run the CLI commands against uh you know uh AWS and uh then we'll look at uh the IM am role and the policy attached to role a and we'll look at uh uh IM am role for role B uh that has the policy to both read and write and uh also we'll look at the trust established over here and then we can basically deploy these two parts and we'll execute into this part and we'll test you know against uh S3 to see if we are able to read from this particular part and we'll also try to to write and see if it fails and then we'll actually read and write from Part B and if everything that uh we did worked then we should be able to both create uh buckets and we should be able to read from the existing buckets okay so first uh step as I as we had seen in the previous sections was was to verify if the IDC provider uh exists uh you know on that uh particular uh uh cluster right so uh we basically uh can run this command and to see the list of IDC providers or the IDC connect providers right so one we we already have one so the description section will have the details of how to enable this now the next step is to kind of look at the rules that we wanted uh for the pods to assume right so let's uh look at uh you know um uh the cluster uh to see uh you know where we have these IM rules uh so let's go back here so this is the cluster H sorry this is the IM rules so we have two rules one is uh to provide full access to S3 and the second role is the redo role right so if you look at the rule that provides the full access this is the policy that's attached to that role and as we had seen the trust is going to refer to the IDC provider over here and one more important thing to note here is that this particular service account and this name space over here that is there on the cluster right so this is something that we are going to create or um or rather see how it's been created so this is what we need to tie uh together okay so let's look at both and uh read only this is the one for the readon so this is the readon policy and the trust exactly as previous uh for rule B so this is the IDC provider and uh then here you see the uh service account and uh the name space and this what uh you need to kind of know associate now this is the cluster as I mentioned and uh this is the YDC provider on the cluster right so let's go back to the eks portion of it and see where how our pods are doing so so these are the parts and uh let's look at the service accounts uh we have two service accounts and one is the default service account and then these are the ones that we created the IDC Ro a and IDC Ro B so let's open one of the service accounts and look at uh the details of that service account so as you can see this particular service account is referring to this role over here the S3 readon role and similarly if you look at the service account B it should be referring to the full access role okay so now the next is let's look at the Pod manifest so we'll look at describe pod and see how pod a looks like so so the important sections here are this over here so if you look at the service account it refers to this IDC service account and that uh kind of refers to the role that we have right so we will now just do a small demo we'll try to execute into the Pod into uh one of the pods and try to look at uh we'll execute actually into both the parts but both part A and Part B and uh part A is supposed to be read only and Part B is going to be both read and right so we'll kind of verify if we are able to do that right so let's just uh get uh started on that so let me just execute into the Pod and uh so I'll just execute into pod a and I'll run the S3 command to list all the buckets so as you can see this worked uh just fine now let me try uh something I'll try to create a bucket and see what happens ideally this should fail so let's uh try to create a bucket called my awesome bucket 0515 and see if we are able to do that so it said access denied which is a good thing right so this is exactly what we wanted we wanted pod a to be able to just be able to read the S3 buckets or list the S3 buckets and we wanted to be able to not write or or in effect create S3 buckets while using pod a so let's exit out of pod a and go into Part B and try to do the same thing so we go to Part B here sorry and uh we try to run the command to list all the buckets so we are able to list all the buckets now let's try what we just did uh previously let's try to create a bucket and uh see what happens boom so we are able to create a bucket so let's uh just again run um S3 LS to see if our bucket my awesome bucket 0515 has been created so as you can see the bucket is listed here right so we want to do one additional uh check here to see if we are able to delete the bucket that we just created so let's try that out uh to see if we are able to delete that bucket uh so let's see uh let me pull up a delete command uh okay so let's see if we are able to delete this bucket sorry okay uh yes uh I think it did it uh so let's try yeah so this bucket doesn't uh seem to be listed anymore the my awesome bucket is gone so this pretty much concludes uh uh the demo so we are able to to uh look at how we are uh you know restricting uh the uh access for part a while we are providing a better uh or more uh privileges or more access to Part B while both are running within the same cluster right so we are able to kind of selectively provide fine grained uh uh you know uh access based on the principle of least privilege uh to each one of these pawns right so if you uh have any questions just you know uh post them on the comment section uh this pretty much concludes the video thank you so much

Channel: DevOps World

Views: 221

Keywords: EKS, OIDC, Service Accounts, Pod Security, IAM policy, IAM Role, Least Privilege

Id: W9oimHq7a0g

Length: 15min 36sec (936 seconds)

Published: Wed May 15 2024