all right and we are live it's great to be here we are uh we're trying something new this time we're we're streaming in multiple places so across uh linkedin youtube and uh of course crowdcast uh crowdcast is the uh the main platform so if you want to uh participate then make sure that uh you head over there [Music] i'm just hearing myself multiple times so i'm fixing that up all right we're good to go now i can remove my stream starting soon banner because wherever we've started uh so welcome everyone i'm so excited to have uh t shin uh with me today to do this uh this uh webinar on kubernetes security we had uh just over 660 registered for this event so it's the largest webinar that we've done so far so very excited to to be able to get into this so let me get started in here i'll go to the side all right so just a little bit of a of an introduction as to what we're going to be doing today so we are going to talk a little bit about what is kubernetes making sure everything everyone's up to up to speed and then we're going to bring in t shin which i'll introduce shortly uh we're going to talk about various security topics now we have a lot to try and back into one webinar so we're going to go through a lot but i just want to say uh i'll share some links uh as we go with this uh to help you so there's a bunch of tutorials everything that we're going to talk about is covered in articles that will be free you'll have access to uh so today you can ask questions uh you'll be able to watch this webinar again and you'll be able to go through step by step of everything we talk about in some articles and tutorials that i'll share with you throughout the way so we're going to talk about threat modeling we're going to talk about pod security network security authen and aussie z and you're going to have time to ask questions so i'd really take advantage of that i'm not going to be able to answer much of them but t shin is is uh is expert and uh this is a rare opportunity to be able to speak to to someone like him of course we have prizes as always um we have some swag bags for sale uh not for sale to give away we have swag bags to give away so participate uh in that we've had some issues shipping the last swag bags but they're out today so i apologize if you won one last last webinar and hasn't received it i promise it's in the mail but this uh if you want to win a swag bag we have rubik's cubes we've got some caps we have some cash cams in those make sure you participate uh participate in the chat participate in the polls that are coming up ask questions if you're in crowdcast which is the main place that you'll be able to ask questions um then there's a bottom at the bottom that says ask a question so please go ahead and use that and we'll get through to them at the end so while we're waiting for everyone to join let me know where you're joining in from so uh uh shin whereabouts are you uh joining us from today today i'm joining you from the central part of china central part of china i would ask what city but uh my my uh chinese geography is uh severely lacking i have to say i'm uh i'm in paris myself at the guardian headquarters we're moving office soon but yeah looking forward to to uh to seeing them oh all right i have some people from florida great things miami be a bit warmer in miami than where we are right now i'm sure for sure some more in france welcome new york lagos houston nottingham belgium egypt colombia france poland oh ethiopia wow we're getting some great ones to date it's so cool to see everyone tuning in from all around the world all right let's get stuck in so quick poll before we get started in the poll section you'll see this here how do you currently use kubernetes are you running self-managed clusters in production are you using a managed cloud provider that helps with that so for example aws elastic kubernetes service i think it's called are you just getting started with kubernetes or do you have absolutely no idea what this terrifying name is let us know on the poll and we'll get back to that in a minute but right now i'd like to introduce the man of the hour t shin so uh t shin was formally uh worked in aws he is a man of many traits we've been working with t shin for over a year i read some of his blogs and i begged him to write for gegardian uh and so he's written uh some great articles uh for get guardian which are all available on our blog um but he's also working on some other projects so t-shin i could i invite you to talk a little bit about yourself some of the cool projects that you're working on at the moment yeah sure okay basically during the past five years i was basically working and living in germany uh munich to be specific i just moved back to china because of the kobe situation and i could never go back to i was working as aws senior devops consultant uh but i've been doing different jobs recently after i left aws i joined huawei cloud leading a 300 people team about developing efficiencies and quality stuff like that yeah um but i'm i'm pretty sure you understand because of the big corporation bureaucratic bureaucratic stuff um that's why i left now i'm working on open source devops two chain manager project yeah uh completely free it's called devstream uh if you're interested maybe maybe you can check it out yeah and i also read some blogs on medium yeah yeah yeah definitely uh follow t shin on uh on medium if you if you can uh he also writes for the guardian blog so you can follow him there which is a great place and uh that devstream um is uh posted below uh there too so i'll definitely check out that project and give it a star uh because it's definitely worth it all right let's get stuck in to the subject of matter titian what is kubernetes can you explain a little bit about about what this what this technology is um and some anecdotes around about that okay so um in general kubernetes is containerization orchestration platform it has been around for almost eight years i would say but during the past two three years i think it has reason it has risen drastically in popularity in the past three years yeah but i think this quick introduction probably doesn't tell you much uh so maybe uh let me tell you a story a story of myself 12 years ago i was working at baidu which is the largest search engine company in china it's a chinese equivalent of google but because there are so many populations there are also a lot of requests we were doing a lot of different services some of which were getting like over a billion requests per day so apparently one host cannot handle all the requests so we have to spin up a lot of instances to share the load so we have two three or even more that's why we need some load balancing back then i believe the term micro service hasn't even been invented yet so we have to do everything manually with the wheels we invented ourselves there is no tool for doing this and because we have a lot of instances we also have to worry about for example automated failover redundancies stuff like that so basically these are the things you will need once your business scale to a certain extent but luckily uh nowadays we have kubernetes it can orchestrate our containerized workload automatically for us it reduces our manual operational overhead so that we as developers engineers uh have time and energy to focus on more important things so that's what kubernetes is to me yeah yeah that's great you know it's funny there's so many people that we we don't even understand that the pain of what it's like we've never i've personally never had to to deal with a server rack or anything like that so uh it's it's it's it's going back and and how fast we we move and kubernetes is such a powerful tool now in dealing with that so uh why should we care about kubernetes and security uh in particular so so what what are what are what are the difficulties in kubernetes that we we need to to deal with i think it's because you know kubernetes as a very complicated platform it's not so easy to set up correctly and run fluently without any issues there are multiple components in kubernetes and it's fair to say that every component is actually quite critical so there is a learning curve and the learning curve is actually not not so flat it is quite steep that is why i think there are so many data leaks or hacked clusters due to misconfiguration for example yeah definitely okay so what we're going to talk about today is really going to come from recommendations that have out of two american agencies so we have the the national security agency the nsa i'm sure if you've watched any hollywood movie uh you'd probably know about them but they have a huge cyber division as well and also the cisa which is a cyber security and infrastructure security agency now what's uh what's important is that these these agencies have published guides about how to kind of achieve that military grade best practices and kubernetes security these form the foundation um now we wanted to write an article about that and t shin is our go-to when it comes to complicated uh topics to be explained uh uh adequately so uh we tasked the process here with t-shin to be able to do this and and this is the guide that we're we're going to be using uh throughout this so it's uh it's been uh a long process to put this together uh and those articles are available on the the get guardian blog if you go to blog.guardian.com forward slash kubernetes then you will be able to find all of those articles there but this webinar is going to cover uh a lot of that so let's talk about the kubernetes components tien can you explain how kubernetes fits together um and the components that make up that uh okay so actually i checked the poll uh just before so i think most people actually do have some background knowledge regarding kubernetes so i will not explain too much into detail but in general kubernetes is made up of two parts one is the control plane which is the rectangular on the on the left side of the p of the future yeah and the other another part is worker node on the right side so um control plane actually it makes um global decisions i would say for the cluster for example scheduling some some tasks right so basically the control plane detects and responds to cluster events for example when you spin up a new pod there will be an event and it's the control planes is a control plane's duty to actually decide where to schedule the part to run to do that uh control plane has actually multiple components the very first and the most important one is a cool api server which is the one in the very center of the rectangular basically it works as the front end to the kubernetes cluster basically it exposes api defines what you can do or how you interact with the cluster and since this is the front end actually utcd is the storage or the backend part of it which is a key value store which stores all the information about the cluster as aforementioned we have some scheduling to do and that is the job of coop scheduler basically it will select a node for a part to run we also have a bunch of controller managers actually it's not just one controller manager but multiple as different controller managers are in charge of different things for example there is a node controller manager which manages the node as the name suggests right there is also endpoint controller manager yeah last but not least i want to mention the one on the upper right corner which is a cloud controller manager because since we are all well not all but many of us are running our clusters in a cloud provider public cloud services so we do have this cloud controller manager which interacts with our cloud and basically when you need a storage we need uh for example load balancer this is uh what the controller manager does yeah that wraps up the control the control plane part then let's move to the right side which is the worker node worker node there there can be multiple ones of course but there are some common components which are deployed on each node for example there is this couplet which works as a agent that runs the pod right uh to run the part you also have the container runtime docker container d etc we also need a cool proxy on this node which works as a network proxy it defines rules on each nodes so that you know the network traffic communication is allowed to the pods there are maybe a few other components that is not in the picture for example we also have a cluster dns which is in charge of uh resolving the internal dns records uh basically that's it yeah okay great so this kind of brings everyone up to speed of some of the components uh of here so now that we've kind of got a bit of understanding let's get into some some of the security components of this so the first step we have here is is the threat model so what what is threat modeling and how does it relate specifically in in kubernetes okay so basically threat model or just any model is just a way to to model stuff so that you can have a better understanding of it in this instance we have this kubernetes threat model and there is not a single model that defines everything we have multiple ones of course for example if you guys are familiar with cncf there is one specifically for financial services related projects right but in my case i'm using a model more or less of myself and this model is made up of three major components i would say the first part is a supply chain risk the second part is malicious actors and the third part is insider threats so let's talk about the first part first basically what supply chain risk means is software risks or dependencies risks nowadays we have a lot of common vulnerabilities and exposures right and we have it in both containers and softwares as well since we we run our workload in containerized parts our docker container has third-party libraries if there is a loophole in the third-party library it can be exploited and on the node we have software software dependencies stuff like that and they also have common cves as well so if a hacker manages to get into the node or manages to use one of the common cve of a certain dependency or software it can actually get access to everything so basically this is a chain supply chain risk um of course there are cves but if uh there is nobody trying to exploit those cves actually it's actually not not that bad right that's that moves us to the second part which is which is a malicious actors we have hackers around the world which is which are trying to find uh vulnerabilities of our cluster trying to get access into our cluster our workload our pod our node right besides vulnerabilities there are also configuration issues because we are we already mentioned there are multiple components of the cluster each component requires a specific configuration so even if there is a single misconfiguration of a simple component can have like tremendous consequences that is a malicious actors part sorry last is insider threats basically this is what the authentication does for example even if we are deploying our clusters in cloud providers uh for example uws right there are still people who actually have physical access to the data center to the hardware they can be insiders and if we are talking about different types of users we have administrators normal users stuff like that and admins may execute any command in containers uh even if we have like row based access control configured they can be misconfigured because it's something complicated right so internal like people can actually exploit those loopholes as well yeah basically that's uh kubernetes threat model yeah all right okay that's that's really interesting but now let's get stuck into the actual the meat of this with some practical examples code and seeing you know how we can secure our kubernetes clusters so let's start with pod security now i think that this is one of the you know the most uh one of the the most important aspects of what we're going to talk about so let's let's start and uh what what is pod security and what are some of the the core things that we need to focus on when we're securing our pods okay sure yeah i totally agree pod actually is the most important stuff in kubernetes because it's it's the most basic building block of everything of course there is container or containers in a pod but probably cannot run that directly so part is like the basic building block if we can secure parts probably we are already 50 down regarding the security issues and for pod security i think there are three i know four components i want to talk about first is running pod as root or rather not running part as root because every container is actually just a running process it is a containerized process but it's just like any other linux process it uses system calls and it needs permissions and that is why all the traditional like linux stuff like this costs namespaces control groups permissions capabilities they are all related to containers um actually that's bad because by default many container services they run as privileged root user so if the process has root privileges and gets exploited you are basically giving the root access to the hacker that is why preventing root execution by using some non-root containers is crucial yeah all right so we have here obviously uh looks like a you know a darker image let's talk about what we can do to to prevent uh containers running and through what are the steps we can take okay sure basically on the upper right this is a very simple docker file it doesn't do much i think most people probably understand yeah but by default this docker container will run as root user and this is not safe as explained there are actually two or three things we can do here let's address two of them one is the docker file user instruction we can specify in the docker file user user id then group id in this case we tell the docker under which user we want to create this docker container process this is one way so if you forgot i think that's bad we need to make this as a best practice follow this idea right um on the other hand we have the security context in kubernetes when we define the part we can have this security context defined here you can have multiple values but for example the most simple and probably mostly used one is raz na root let's make it true so that if the container runs as a now root user it cannot be created at all yeah okay yeah great it's very clear so uh moving on we have the immutable file system so using this wherever possible can we explain what what that is why that's important and then we'll get into some code of how we can implement that sure yeah the second part i want to talk about is file system so by default containers are permitted mostly unrestricted um they can do any execution within their own context which means they can probably save something into the file system if we use the read-only immutable file system right it helps to enforce a immutable infrastructure strategy the container should only write mounted volumes that can persist even if the container axis right maybe let's have a look at an example yeah on the right side i'm pretty sure most people have done this when you try to do some debugging in kubernetes right we run kubectl exec to start a shell and get into the container and do some debugging stuff for example maybe we need to create some files or we need to change some source code maybe we even need to run some commands and download some packages stuff like that yeah just like the example shows but the thing is a hacker who has gained access to this container can also create files and download scripts and modify your applications or source code within the container just like what we did when we were debugging right that is why immutable file system is important to most containers because actually a lot of containers don't really need to write the root file system for example if we are just building a web application we don't really need to write something to the root fest uh it's also a good practice to reinforce the really only root fs as true yeah okay so uh now image scanning we've talked about this before right because get guardian we can scan docker images for for secrets uh we have a webinar on that too you can check that out in the archives but uh you know we're going a bit further in that we have a tool here an open source tool that that your recommended why should we uh scan our images and uh and and what what further should we do from that okay so since we're talking about pod security uh we have to talk about the images because images are the base on which parts are created right if we talk about the images um basically there are two ways to create them the first approach is to build it from scratch but we really don't do this very often the more common way is to build a darker image on top of existing one for example in the previous example we have from something the from something is a base image since we are using a base image which means we are using someone else's image we must use trusted images from trusted repositories we cannot just use any image out there and even if we are already using a trusted resource we still need to scan it because maybe the base image has some known cves that is why image scanning is also crucial to power security of course there are yeah sorry so i was just going to say you know and when when should we do this image scanning is this something we need to automate is it something we do manually is it something you know like how do we set up secure image scanning yeah actually we have multiple ways to do this manual locally is all always possible right but it's not automated which means we have some manual overhead so we can integrate with our ci cd systems besides city there is also a kubernetes admission controller which is a kubernetes native feature it actually intercepts and processes requests to the api calls before the execution which means before the party is created we can do something and if this something scans the image it enhances our security yeah okay great all right so let's talk about the pod security policies ps uh psps uh what are these should we be using them and should we continue to use them uh in the future okay that's actually a great question so what is psp basically this is what the name says is part related security policies it has a lot of features for example you can deny a part that runs as root in the previous example we mentioned how to use the user instruction and the security context to decide under which user the container is running but it's not actually enforced for example if i forgot to write those or even if i don't really want to write it we can still run it as a root user but the psp can be enforced it's a reinforced policy we have other features for example run as a specific user as a group allow privileged escalation and etc yeah but actually there are a lot of usability issues with psp because it's actually quite confusing as shown here is complicated right it's easy to to go wrong and when it goes wrong it's really hard to debug in order to improve psp there must be some breaking changes and i think that is why psp has been deprecated last year in the 1.21 version at the moment you can still use it and actually it's still recommended to use it but it will be removed in one point 25 i believe probably three to six months from now yeah um let's replace this yes yeah no continue sorry sorry sorry no i mean uh i want to talk about the replace replacement for psp because kubernetes is releasing another stuff which is called power security admission controller it's already beta in the current version and out of the box it already meets the most common security needs so basically it's a much easier to use version of psp and there is official way to migrate from partner security policy to the power security admission controller yeah but because it's still in beta today we will not talk about it for martial okay so we should still be using psps today uh as a best practice but but know that you know there it has been deprecated and there is a a solution that is uh you know less convoluted let's say uh coming up important all right so we've come to the end of of pod security so we can kind of move forward now onto our network settings um so so what what what is it about the network what are attackers looking for in in network vulnerabilities um let's start start there and then let's get into some diff individual examples okay this is because actually all the components and uh the control plane and the nodes they communicate over the network that is why networks is crucial here we don't really access the component directly we access the kub api server and api server accesses other components even calls different nodes stuff like that that is why network security is crucial to kubernetes here i think there are a few things to to talk about for example we need to deny some unnecessary access to the control plane to the etcd if you are using a managed service communities maybe there are some things to do if you are using a self-managed kubernetes cluster you can also use like net for example security groups to regulate the network traffic okay so so let's start let's start uh you know denying access to the control planes and nodes so so um yeah i'll uh so in this example using a managed control plane so we're using a managed service like aws elastic yeah for example in aws uh eks elastic kubernetes service uh we don't really own the control plane but rather is a service out there but still we can't define a security group around it and we can define what the security group allows which port you can listen to stuff like that also if you have multiple clusters for example you can use different security groups for different clusters so that there cannot be any overlapping between unrelated clusters this can be a best practice yeah we have a few maybe later yeah okay so let's uh let's talk about self-managed kubernetes now and what and what we need to uh to talk about uh i mean here i mean uh and we have some some ports here just something quickly that we can we need to worry about when we're doing self-managed clusters yeah exactly um i think at the moment there are multiple ways to create a self-managed cluster yourself for example we can use terraform we can use aws eks ctl if you are using other cloud there are always another option right there are even companies who installs kubernetes clusters as a living there are different ways but there are some common practices to to share for example we have some common ports as shown in the table below the control plane different components listen some different ports so we can use the security group to allow only certain ports to be listed and that's it so that we don't increase attack surface i mean if if we expose some random ports or unnecessary ports this increases the chance that a hacker you know maybe if he can get into it uh that is a extra thing to consider if we are managing the control plane ourselves right so we have some ports here from the control plane yeah and then also some ports here from uh from the worker that and basically we want to limit access to just to just these ports uh for obvious reasons right we don't want to to have to allow multiple gates into into our area yeah exactly because control plane is like the core part and the worker nodes is actually handles the workload if we get access to the worker node and we are not limited by any security group any ports dangerous things can also happen that is the reason we also need to limit uh network access to the worker nodes okay so let's talk about uh now let's talk about namespace separation so maybe you know for people like me uh you who aren't super familiar let's what what is the name space and then what does name say separation okay so a kubernetes namespace is actually the way to partition the cluster resources among multiple individuals or teams or applications within the same cluster some people try to do this to achieve like a multi-tenancy we have different tendencies inside the same cluster which are separated by name namespaces so for example in this picture we have two namespaces and inside each namespace we have different services and parts running the thing is by default the namespaces are not automatically isolated but we can achieve this by using network policies which i believe is in the next slide right so parts and services in different name spaces can still communicate with each other unless another additional separation is enforced by other network policy we have an example of the network policy code on the next page yeah uh basically a network policy controls the traffic between parts and name spaces and even external ip addresses like that by default there is no network policies applied to any part or namespace resulting in unrestricted ingress and egress traffic within the network but for example if you have two namespaces like the previous example and you want to separate those two namespaces we can use network policies to achieve this this is i believe this is the only way to truly separate network traffic between namespaces and to achieve multi-tenancy inside the same cluster yeah all right now this is a slide that i like secrets management so everyone that knows because it knows we're all about protecting our secrets so uh how does this relate and translate into you know the workspace of kubernetes and specifically network security what are we looking for in protecting our secrets in this environment yeah basically secrets store like important stuff that's why we call them secrets but the thing is uh secrets they are stored in the utcd uh and inside the kubernetes they are stored as base 64 encoded format it's not encryption but rather encoding right if we are using kubernetes as a service for example aws eks the chances are all the utcd volumes the utc etc backend storage volumes they are already encrypted at the disk level so basically this is the data at rest encryption but if we are deploying our own kubernetes cluster this is also configurable we need to pass some argument so that the encryption is enabled by default and since i think to encrypt the disk to encrypted volume is not enough because secrets in kubernetes cluster are just base64 encoded um if you can read it you you can read it right everybody can read it um and when the secrets are created in the first place it's highly likely that we are creating those secrets with with some yammer file so we have to put the clear text into a file and what do we do with the files right after the secrets are created we delete them what do we use i mean how do we share the secrets across teams and individuals right and i think this is where the secrets managers actually come to help it acts as a single source of truth where you store all the secrets encrypted for example hashicorp has vote right aws has the secrets managers and there are other equivalents as well by using those sequence managers we can actually store the secrets near external sequence manager make it much safer and when we are launching a pod running workload we can always use the secrets directly from those sequence managers there are different ways to use it yeah this is one way another way i want to mention is the external secrets basically it allows you to use external secret managers secrets managers but use it in a kubernetes native way so you don't have to change much yeah right got it and uh um and just mentioning again that if you want to check out the tutorials and stuff you can go to blog.com forward slash kubernetes and uh you'll see teeshin's articles in here uh we this morning took some some out of the webinar because we wanted to kind of like talk about uh how to set up this but it was too much for for for this webinar but we have t shin has written some great examples of using external secrets here um that project and added an example so if you want to learn more about that uh definitely check out uh check out those articles and tutorials there but let's move on move on away from uh from network this is our last subject authenticity so can you speak a little bit to shin about what these are um uh you know to start with and then we'll dive into some of the security measures that we need to take around them okay so basically authentication and authorization handles the insider part of the threat model inside kubernetes we have different types of users for example normal user accounts and we also have service accounts and the service account actually is quite dangerous because if we authenticate with a service account token it's actually very dangerous because the service accounts handle api requests on behalf of pods if we have the token basically we can do everything in the in my article actually i have a very hands-on example where you can follow and experience it when you have the token you can basically access the coupe api and everything yeah that's why authentication and authorize other authorization is very important since we're on the topic rule-based access control is also quite crucial here we also need to use the least privilege principle so we don't give more principle than needed to a certain user or to a certain group of users if we are using like kubernetes as a service for example using aws eks there are a few best practices to follow as well for example maybe we can make the cluster endpoint private wherever possible if we don't have to access endpoint from a public internet we can always make it private we can also use dedicated im roles to create clusters we can also use im rules to authenticate like normal real users and yeah stuff like this so i think i cannot hear you oh sorry i have a okay my microphone there it was off sorry uh let's talk about some user types here so so what can you talk about the kubernetes user types and what should we do in terms of security basically there are two types like normal user service accounts i think the key takeaway here is not to use service accounts token to do anything because that's dangerous as explained yeah and we talked about this of of of leaf's bridges here so obviously important to continue with that yep we already covered this part briefly and okay yeah for well let's let's move on to the last section that we have here logging and auditing so uh kubernetes logging where's the security vulnerability in that and and what process does auditing take in terms of kubernetes and security okay so auditing actually it provides a security related chronological set of records that documents the sequence of actions in a cluster right that is why we need the auditing the cluster all these activities generated by users applications that use communities api it also monitors the control plane itself we also have audit policy which defines different rules about what events should be recorded and what data should should the record have we have different examples in our articles as well yeah but regarding login and auditing they are not too much to do's right there are basically only two action items first is enable it because it's important and the second is enabling it alone is not enough we also need to regularly audit it we need to regularly audit who has access to what and there are some tools which can help us to do this um for example we have a tool called kubectl huka it's a command line tool i believe it's open source as well free free to use you can run the command and see who can do what with just one single command there is another one which is great rbac lookup basically it does uh checks or queries on different verbs and different things it shows different row-based access control policies so that we don't have to write a lot of google commands to get the roles together low bindings to get cluster rules stuff like that yeah okay great so everyone get all of that [Laughter] so uh tisha thanks thanks for going through that now we're gonna go through and uh have an opportunity to to ask some questions of course i know that this is a lot to take in we purposely kind of kept kept things at a high level with some examples but we do have those in-depth uh details where you can work through t-shirt has code examples and pull requests um to to help help you do that see before we before we move on to the next section which is we're going to ask some polls and get to some questions what you know for people that are actively using kubernetes and and production whether they're managing it themselves whether they're on a uh using a service like aws what what is important what does what are some of the key areas from everything that we have just discussed where do we start with security um and how do we know how do we we know that we're keeping up with everything in security we haven't planned this question so i'm throwing you in the deep end here okay sure yeah i think this is actually a very broad question it's very good and it's difficult to answer because kubernetes is too much it's a lot of things so i would say first stop worrying too much if we think about everything maybe we cannot achieve anything right so basically pick a point uh maybe some incident already happened related to security right fix that do something about it um try to improve pod security try to improve network security maybe you try to review your terror from script with success of the cluster and see if the security groups are well defined things like that start from small stuff and review like periodically to see if there are if there are any missing items yeah okay great so uh here's another poll that we have in there if you haven't filled it out let us know how do you feel about kubernetes are you a kubernetes pro do you feel at home spinning up these clusters uh do you have some knowledge do you understand the key concepts but still learning that i think i think i'm in that category there where i i can say some acronyms that sound like i know what i'm talking about but you know when it comes to hands-on ability i i think i'd be uh lacking or is kubernetes bloody terrifying for you uh let's let's see uh how we all feel in the polls right now so the preliminary results is that everyone seems to have some knowledge we you know 49 50 49 49 votes so far said that they have some knowledge we only have six people that think that the kubernetes elite um you know and then a lot of people that uh like me and a lot of about 21 people so far i think it's it's terrifying i can i can relate to that i'm probably in between uh those two you know but i liked what you said before in the wrap-up because i i just want to read it you know don't be afraid get going kubernetes is a lot um and i think that's for me too it feels like so much can go wrong uh that that it you know you don't even want to start but i think acknowledging these these security issues that we're talking about at t-shin um has given us is a great way to be able to move forward um from this because if we secure if we at least have the basics of security then we can move forward confidently um confidently in in what we're doing now um i just want to remind everyone that if you're watching this on linkedin or watching this on youtube i think there's three people watching on youtube at the moment but head over to crowdcast if you want to ask questions uh you've got a little bit of time left i've got the link down there uh it's probably in the description of where you're streaming from because that way you can participate and ask some questions now we have a lot of questions uh to go to go in here uh i do want to point out if you go into the ask a question tab there's one there for me uh i'm curious to know how everyone found out about geekguardian so leave a comment and let me know how you found out about your guardian but right now let's go in and and asked some some questions here so we have one uh first one here when you have compliance policies how do you enforce compliance at run time for example to ensure that encryption for your internal pod communication how do you know where there's a pod that is not following the encryption channel does that uh does that make sense to to youtube do you have comments around that question yeah maybe i can answer a little bit i think this is a great question because a lot of companies has different rules right maybe i can mention two two things first is uh pod support communication encryption maybe this is what the mutual tls does we want the transport layer security um a simple service mesh can enable this by default so maybe that is one way to go another is container runtime security platform there are many choices i would say uh for example previously we talked about a little tool called trivia which scans docker images i remember the company who made that tool is called aqua security they also build a container runtime security platform which can monitor your workload and traffic real time in the cluster okay great all right we have another question here is enforcing pod security via service accounts um we have uh like versus cluster role the new way to go slash best practice for securing the cluster i wouldn't go so far as to say is best practice i mean this is one way also there are different preferences for different people different teams so pick the method that you feel comfortable with i think yeah okay another question here is there a specific tool for security of pods deployment in kubernetes like log.trace.metrics we have in grafener so i'm not sure if you're familiar with that tool but uh do you know if there's a specific tool for security of pods deployment for pause deployment um [Music] the container runtime platform can can do that but it does more than that so i don't know if there is a specific especially open source tool that focuses on project security only yeah not sure if that answers the question great okay uh oh this one i can answer will you be will you share a recording yes yes we will share a recording this will be available on crowdcast uh after um and we uh will also be on our youtube channel um yeah there's plenty of uh great content on our youtube channel around about security we're trying to expand it out so uh always appreciate a subscribe and a like um over there so you can find us by googling uh by just going on youtube and looking for gear guardian i would appreciate uh you guys joining us over on the air okay let's get back to some questions here if a breach happens and detected can the pod destroy itself i like this question can the pot destroy itself well um i don't know maybe yes but i i i haven't seen this before but i'm not saying this is not impossible yeah okay having a look what is the best way to allow access to the developers to the to allow access to the developers for the cluster and manage our back permissions any tool suggestions tools not sure suggestions if we are using like cloud-based services for example aws we can map different users to different groups and we can grant access to the group only i mean if we have multiple developers especially tens or even hundreds uh if we manage them by by users it would be quite messy you have a lot of things to worry about but maybe we can map them to groups and we manage by group yeah if you are using aws eks there is a config map where you can do this yeah okay great i'm so glad you're answering these uh these [Laughter] myself questions great it's great information we're trying to try and get as much as we can we have 23 questions that have currently been asked so i don't think we're gonna get to all 23. um but if you look in the questions what's going to help if you upvote the ones that you like because then i'm going to see i have more chance of seeing them and we'll do it we'll do a couple more uh before we go okay so we have someone here that's uh that missed it is psp deprecated only because it's not intuitive to use or is there a critical flaw with it um so i think an important question is to whether or not we should continue to use psp or not um [Music] okay is it deprecated only because it's hard to use no i would say yeah flaws i also wouldn't go so far to call it as flaws but in order to improve the usability the changes are breaking changes that is why it's not possible to continue building on top of that and that is why it is deprecated yeah at the moment i think if you are just started maybe you can get a feeling about pst because psv basically does the same thing as a replacement except the replacement is much easier to use maybe you don't even need to configure much it can work out of the box um at the moment it's better beta i'm not sure for a lot of companies beta probably isn't good enough so start with psp first get a feeling then migrate because uh the migration is supported officially okay cool so i mean it's not like if you're starting to use this now that yeah we then have to forget everything the tool used is definitely based on the same concepts that's what i'm i'm hearing and uh it's just an improved version of this but uh psp doesn't have any critical flaws that would prevent someone from using it right now no definitely not yeah okay great do we have it do you have any recommendations for runtime security tools runtime security tools okay i have been using a few i think i think there is one from i think it's called prismacloud maybe it got renamed later aqua security has one uh there is also uh cystic falco i think this thing is open source falco is a business product around it yeah i have a few experience with all of them maybe i can recommend 6d but it's only a personal opinion here okay great i think i'm gonna go for for for one more question then we're gonna announce the winner of uh of the the swag bags here uh okay um trying to find one that uh okay for developer not managing the cluster but using it uh and creating namespaces what would be a good solution to manage external secrets that are not part of the infra the infrastructure but are needed in the app for example an external api key is it okay for example to leave them in the cluster and not document in the repo leave it in the cluster not documented in the ripple i don't think that's a good idea because in this way you are using the native kubernetes secret as the single source of truth and as explained it's only base64 encoded what i would do is to to put it in a secret manager for example hashicorp vote and inject the secret into the pod there are two different ways to inject it maybe we don't have time for that but each way requires some some changes to your yaml file if you don't really want to change anything to your demo you don't want to inject anything maybe try external secrets external secrets is another custom resource which you just apply and it can re-think the secrets from a secret manager to communities yeah okay great well i think we're going to leave the questions there uh t-shirt you have been what a relief yeah uh a world of really uh okay so let's let's let's have a quick look uh we have two swag bags to give away today uh i think if we're gonna keep having we had 699 people register for this uh and uh 284 have attended uh have attended live so i think maybe we need to give away a couple more uh swag bags in the future but uh uh we'll we'll we'll stick to this so uh we're looking for the people that are most active in the in um in the chat and the most uh uh upvoted uh questions uh okay and we're gonna pull a uh i'm gonna post this name in the uh in the chat because i'm really sorry but i am not sure how to pronounce it i'll i'll give it a go so the winner of the first swag bag omar laid uh akinwum i'm i'm i'm nearly certain that i've butchered that and i apologize but congratulations i'll email you um and i'll get an address for the uh uh for the um uh for the address of the swag bag and the other person uh who who got the most amount of votes on the questions that they asked uh uh fabo uh komplani uh you have also won a swag bag again i'll uh i'll post that in the in the chat there and i'll i'll be in contact with you um uh okay see it all right we have a form that is in the chat that ziggler has been posting and uh i have not been promoting i i am very sorry so uh before you go we'd really love to hear about you your feed your your feedback here um um uh around infrastructure as a code configurations so can you please help us out uh it will all become clear why we're asking these questions in the future uh but uh until then we would be uh super helpful uh and and finally to uh if there are any um if there are any uh further questions uh oh sorry finally if there are further topics that you would like us to discuss in this webinar can you put your ideas in the chat uh we really want to hear from you guys uh what information you're looking for so that we can provide that for you for you we'll try and find amazing guests like t shin i'm sure everyone will agree that t shin was uh unbelievable here he answered the the most difficult questions we've had on the webinar by far uh and he did it without breaking a sweat so uh so thank you so much t shin for thank you exactly um so please let us know if you want any other any other types of webinars and we'll do our best to get great questions for that now i have one other announcement here i'm just going to share my screen uh before you go and that is that teaching has a brand new blog on the get guardian website which is uh nine terraform best practices now i believe if it's not live right now it will be live in a few minutes uh but this is a a great article it's not kubernetes related but it's from the master himself self t shin so you know it's going to be good you know it's going to be full of information so make sure you head over and check that out you can view that on our blog it's a blog docketguardian.com and if you want to find more if you want to go through the examples that we've talked about here uh then on our blog if you go to blog.guardian.com forward slash kubernetes you will find a list of teachings articles that talk about high level and also go hands-on tutorials uh so yeah t-shin uh i personally just want to thank you so much for your participation uh today it's it's been uh great uh having your world of knowledge and i really hope that we can have you back on the webinar in the future perhaps uh with a different uh with a different uh uh topic there thank you thank you it's my honor yeah uh all right guys that's all we have for today so uh uh just to to finish up make sure you check out the geek guardian blog for great articles let us know what type of content that you want and uh please jump over to our youtube channel and give us a subscribe and a like there we do our best to try and get you the best content uh for here so thanks so much for participating uh congratulations to those that want swag bags and hopefully i will