 Hello everyone. Thank you for joining this session. My name is Mario Vazquez. I work for VAHEAD in the Telco engineering group, helping our partners and customers to run their 5G workloads on OpenShift. And today with me I have Alberto Lozada. Thank you Mario and thank you everyone for joining this session. My name is Alberto Lozada. I work at Redfield as a senior software engineer currently focusing in the telco space. So my background is mainly systems administration. I work as a security consultant long time ago. And for the last 5 plus years I have been involved in Kubernetes and OpenShift. So in these 40 minutes, 45 minutes presentation plus questions, we will deal with the security context constraints, short and SCCs in OpenShift, which is a huge and dense topic. So the main goal after this presentation is that you understand how SCCs can help you to limit the permissions given to your applications and how your applications can run or how you can configure them with the minimum required permissions in the OpenShift world. So let's move to the what are SCCs. So let's put some context first. So historically Kubernetes didn't have any way to apply security policies to the applications that were running in your cluster. So basically all applications could get high privileges. They could run as privileged container, which means that they could use any current capability. Any Syscall can make any Syscall pretty much the same as a privileged process in your system. So Red Hat, since it wanted to be a Kubernetes offering for enterprise customers, so realized that lack of security policies to have some kind of control of what applications can do in the Kubernetes clusters. So SCCs were included into OpenShift from the very beginning and they are still an OpenShift thing since they were not merged into a Kubernetes upstream. Unlike role-based access control, for instance, which started being OpenShift-specific and now it's part of Kubernetes out of the box. So by default OpenShift scans with SCCs. So when you install an OpenShift cluster, it comes with eight SCCs actually that are thought to cover most use cases. It is worth mentioning that there were some similar security controls introduced into Kubernetes like the pod security policy, but didn't flourish. I mean, the currently PSP is appropriated in Qube 1.21 and also there are some other proposals by the community. Here you can find a link in the slides if you are interested like the pod security admission and there are others like the OpenPolicy agent which some folks are using as a replacement. But what are SCCs? What are security context constraints? So similar to the way that role-based access control controls user access and authorization the administrators, the cluster administrators can use security context constraints to control permissions for pods. So these permissions include actions that a pod, a pod in a collection of containers or one container, so actions that a pod can perform. For instance, it can change the owner of a file or the pod can run as a root but also include the resources that this pod can access from the node it is running. It can access to the network, to the host network or even to the file system of the host the pod is running. So SCCs is a Kubernetes resource that defines a set of conditions that a pod must run in order to be accepted into the system. And I want to be clear here, so SCCs are not added directly to a pod. They are assigned to users, so this user or service account is the one responsible for running the application for running the pod and those permissions or restrictions are somehow transferred to the pod. Okay, so it's important to note as well that SCCs are managed only by cluster admins in OpenShift, so cluster admins can create, delete or modify SCCs. And here you can see a list of things that SCCs can do. So an administrator, when they create the SCC resource, it can control if a pod can run privileged containers. So, I mean, with that I mean, even if the user sets the security context specification of the pod as privileged equals true, so the developer configures the pod specification and sets this flag to true, if the SCC does not allow it to do that, then the pod will fail to start. I mean, so there are other things that an administrator can control, like the capabilities given to a container, the SC Linux, the user ID, the user that is running the container, etc. Summing up, I mean, so I want to be clear here, so summing up with SCCs, you control a lot of permissions that your application may or may not have, so one of these permissions that can be managed, for instance, are capabilities, or set in another way, so in an SCC resource, a cluster admin can add, remove or allow to add capabilities in their specification section. So what are Linux capabilities? So let's explain them a little bit first. So in traditional Unix implementations, previously to kernel 2.2, there were two categories of processes, I mean, privileged processes running with effective UID 0 that can bypass all kernel permission checks, and there are another kind of processes called and privileged whose permissions are always checked to be sure if it can execute the task that they were requested. So the idea of capabilities is simple, so just split up all the possible privileged kernel calls into groups of similar functionality. So then we can assign the processes only the subset of privileged kernel calls they need instead of the whole cake. So I think the picture represents here very well the concept. So we can see how in previous kernel 2.2, root had all the permissions, then it were, I mean, the permissions were divided into groups of capabilities, and then it is possible, even possible to restrict capabilities from even the root user. So we can see in the last picture that the root user doesn't have all the capabilities, all the permissions. And remember, so I think this is the takeaway here in this slide. So the power root doesn't come from having the name of root or for having the UID 0. So the power root is based in a concept inside the Linux kernel called capabilities. So in OpenShift, you manage kernel capabilities that are given to your application through SCC. So for instance, here you have a few examples of capabilities that can be managed in OpenShift, for instance, the NetRow, which is used to manage row and packet sockets. For instance, the ChanChowner, which makes arbitrary changes to UIDs and GIDs. You have also the famous NetBindService, which I think it's required, it's needed for allowing the users to open up a port below 1024. And from network capabilities, for instance, comes to my mind the NetAdmin. Also, it's important because it basically adds no restriction in controlling network interfaces or configuration. I mean, you can configure the NIC to cop tour traffic. It allows you to configure the NIC to control traffic. So in OpenShift, some of these capabilities are configured by default in the Cryo container runtime. I mean, if you are interested, you can take a look at the Cryo-enabled default capabilities in the link included in this slide. So these default capabilities that are included in Cryo are assigned to every container, but it doesn't mean that they are effectively included to all containers. So actually, as I mentioned, the SECs can add, can drop or allow capabilities to your applications and you can end up running your application with less capabilities than the default ones given by the runtime. So that's, for instance, the case of the restricted SEC that we will see later. Another important concept is that capabilities are handled at runtime and are independent of the container image. So you can launch a development version of a container and give it tons of capabilities in a development lab, for instance by assigning a permacive SEC, but then launch the same container in production and assign a different SEC which gives a very few set of capabilities. So SECs in OpenShift makes it easier to manage capabilities. And yes, finally, last but not least, there is no magic tool that will tell you which capabilities are actually required to your application. So it is or should be the developer of the application who is in charge of knowing the capabilities that are needed to run the application. Another security feature that can be managed by SEC are the secure complete profiles. So SECOM can be seen as an instead farther in setting the minimum required permissions to your app. So as written many times, I mean containers typically run a single application. So SECOM or security complete profiles allows for filtering the CIS calls directly, the CIS calls invoked by that process and then can be used to restrict which CIS calls are given application is allowed to execute. So previously we talked about capabilities which can be seen as a group of CIS calls and now we are dealing with CIS calls at a much lower level. So SECOM broadly set can be seen as a firewall on CIS calls. So you are actually allowing or denying CIS calls from your app. And there are many projects that are actually using this technology like Android, Chrome or Flatpak etc. OpenShift ships with a SECOM profile that is used by default unless otherwise specified and can be found in each node in the ATC cryo SECOM.json file. We will see an example of the format of this file in the next slide. So the default SECOM profile limits a lot the number of available CIS calls. Of course it can be replaced that you can create your own SECOM profile into the nodes and then create a new SEC to select the proper SECOM for your needs. Creating SECOM profiles that it has been mentioned with capabilities require the knowledge of the application. I mean knowing CIS calls, the CIS calls that are executed etc. There are some tools like the OC SECOM BPF project mentioned in the slides and this project sets up a potman hook and intercepts the CIS calls executed by the container. It will even list them in a JSON file which is ready to be used as a SECOM profile out of the box. So it is worth taking a look at the project to understand better SECOM and CIS calls that are used by your application. And also it's important to happen to many of us when make sure if you are using this project when creating SECOM profiles you are using it with potman so select the proper runtime of your Kubernetes distribution since different runtimes may execute different CIS calls. So in case of OpenShift it is using the run C container runtime under the hood. So this is an example of the SECOM profile JSON structure that I mentioned before. So see at least for me it's like a firewall configuration so there is a default action if the CIS call is not in the list which in this case is the action equals to ERNO which means the night. Then it comes the different architectures applied. Notice that the architectures are important since CIS call IDs doesn't have too much CIS call names in all architectures. And next we have the right list of the CIS calls explicitly allowed in this case. So finally and recently as well you can use also the new action called NCMP-ACT LOCK to find out which CIS calls are required by your applications. I mean you can use the project that I mentioned in the previous slide but also you can use this in a similar way as a Selenium experiments if not for me. I mean this lock action will allow all CIS calls. I mean no one is denied and will lock the ones that are not explicitly allowed to an audit lock file. So then you can take a look at this audit lock file and check those ones that probably you need to explicitly include, explicitly allow in your application. Okay so until now we describe it with our CIS. We define what are capabilities and second profiles and we also know that they can be managed by CIS. So next what we are going to do is visit the eight default CIS that comes in OpenShift. So these are the ones that comes by default with any OpenShift installation. We will go deeper into each one but although these are expected to cover most use cases as mentioned it cluster admin can create custom SCCs to meet their needs. One thing that is important is please do not edit, delete or change these eight ones. Do not modify them since it can cause damage to your cluster. I mean take into account that there are OpenShift infrastructure components that are used in these SCCs as well. So if these eight of the ones that are here doesn't meet your requirements please create a new one. So the first one is the restricted SCC. So this is the security context constraint used by most of the pods and the most restrictive as its name implies. So it is granted by default to all authenticated users. So this means that if you create an account, I mean a user or service account this SCC will be granted and not only this one to the new user. So in the case where this SCC is applied to the user running your pod or pods the restricted will ensure that the pods cannot run as privileged so it will also ensure that the pods are running with a pre-allocated range of UIDs instead of UID 0 or any other user ID or I mean UID 0 I mean root. Same for the MCS, I mean the Multicategory Security which is part of the levels SC Linux context. So you are forcing your applications to run with a pre-allocated SC Linux label assigned to the namespace and cannot be changed with the restricted SCC applied to the application. However, this SCC actually allows to use any supplemental groups to your pod so in case you need for instance accessing to share a network storage you will need a supplemental group so you can mount this storage remotely. Obviously the restricted one does not allow you to access to the host file system or host network directly. So this is the most secure SCC and it should be used always if possible. Second one is the Any UID SCC which provides the same features of the restricted SCC but in this case allows users to run with any UID and any GID so this means that you can set in your pod configuration that you want your applications to run as a specific UID even as UID 0 so if running as root then it means that the container process is running as root in your node, I mean both inside and outside the container. So however, don't panic, I mean take into account that SC Linux also plays an important role here at INAA, a layer of protection to the node. The third SCC is the Host Access. Host Access permits access to all host namespaces which means access to the node file system, PIDs, IPC and network. However, it still requires pods to be run with a UID and SC Linux context allocated to the namespace. Anyway, this SCC should only be used by trusted pods so grant with caution. Next one is the Host Mount Any UID so it provides all the features of the restricted SCC but allows host mounts and any UID by a pod. So this is primarily used by the persistent volume recycler but if you are using for something else be careful since you can mount host volumes and also set the UID GID of your container to any. The fifth one is the Host Network SCC it allows using host networking and host ports but still constraints ports to run with a UID and SC Linux context allocated by the namespace. So this means that with this SCC you can execute pods that will be able to see, use and attach the node network directly. So an example in OpenShift of a pod or of an application that is using this SCC is the router pod which uses this SCC to listen in port 80 and 443 in the physical network of the worker nodes. The next one is the Node Exporter this must be used only by Prometheus as you can see has a lot of permissions host access to file system, PID, network plus running as any user so please do not use it it's used for monitoring only. The sixth one is non-root SCC so this is exactly the same as the restricted one but in this case you can configure your pod to run with any UID except root or UID 0 I mean we can say in another way so it's exactly the same as any UID but you cannot use 0 I mean you can choose any other UID except being root so this is mainly used by applications that need a predictable user which is not root and there is no other permission required so I can imagine for instance a posgres database container that requires a specific user or maybe an image, container image that has been built with a specific user and cannot be changed to run with the ones that are preallocated by OpenShift and finally the privilege container I mean it permits as you can see access to all privilege and host features and the ability to run as any user any group, any FS group and with any cylinders context so it is clear that's the most relaxed SCC and should be used only for cluster administration so this SCC allows a pod or a container I mean to control everything in the node is running so only trusted workloads should use it and even we can discuss it if it makes more sense to create a custom one a tellerate SCC that meets the requirements of your app application and as an example of applications that are using this privilege SCC in OpenShift is the tune-D operator or tune-D application since it needs control to the host in order to apply the different tune-D profiles and it needs access to low level configurations and I would like to note here that even if your application is using the privilege SCC it doesn't mean your pod is privileged I mean you must explicitly configure the pod to demand that privilege and now we are going to talk about OpenShift SCC strategies and I will hand it over to Mario Thank you Ruto So in this slide we are going to introduce the different annotations that are used by SCCs so in OpenShift every name and space will get three annotations related to SCCs by default so the first one is the MCS one which basically defines the Selenux MCS configuration that our pods will get by default then we will get a group a range of supplemental groups groups IDs that we can use so in this case this will be the first group ID and then we have 10,000 more groups IDs that we can use after the first one and the same goes for the UID range so we get a range of UIDs that we can use in our pods this will be the first one and then we have 10,000 more okay and then the objective of these annotations or of these settings is to provide a better isolation between projects so for example every project or name and space will get a unique Selenux context and UID, GID range so other name and spaces or projects cannot use these ranges on their applications next we are going to introduce the different SCC strategies that we have SCC strategies control the security features that a pod has access to there are four different SCC strategies so the first one that we define is the run as user which basically controls which user IDs can be used by the containers in our applications there are four different configurations the first one is must run as which basically defines a specific UID that has to be used by the application the second one is the must run as range where we define a range of UIDs that can be used and any UID between that range inside that range can be used by the applications then we have the must run as non-root which means that every UID can be used but the UID 0 which is the root UID and then finally we have the run as any which basically means that you can run as any UID including roots UID 0 next we have the selenux context which basically controls which selenux context is used by the containers as we mentioned earlier our name and space will get will get assigned one default MCS setting that's what will be used if we are running in must run as mode then we have the run as any where we could change the selenux MCS configuration for our pods then in supplemental groups these controls which file system groups are added to the containers supplemental groups and this is mainly used for search threads there are two possible configurations must run as and run as any in the next slides we will get into the details of the supplemental groups and on the next setting which is FSROOP so FSROOP basically controls which file system groups are added to the container supplemental group it's used for block storage mainly and again it has two possible configurations must run as or run as any next topic is the privilege escalation so the allowed privilege escalation controls whether a process can gain more privileges than its parent process so this boolean directly controls whether the non-imprips flag gets set on the container process this setting, the allowed privilege escalation will be always true when the container runs as privileged container or has the cis-admin capability and this boolean that we are talking here the non-imprips is consumed by the system calls as you can read in the current documentation then the Kubernetes design proposal for getting this boolean added can be found in the link in these slides and then if we have a process that has the non-imprips what will happen is that that process or their children cannot gain any additional privileges the process cannot un-set this boolean once it has been set process cannot change UID or GID or gain any other capabilities even when you are using set UID binaries or binaries with file capabilities and then Linux security modules like Selenix can only transition to a process type with fewer privileges and you can continue reading about this in the link on the slides but still this might sound scary but being able to run privileged escalation operations is required under certain circumstances like for example when your application uses set UID binaries or when your application uses binaries with file capabilities you can see some risk but in this case even if file capabilities can cause a privileged escalation we have great tools today to avoid pods from getting such capabilities for example via SCC where the restrict SCC that's a pretty good job limiting the number of capabilities available for pods by default on the other hand we have the becoming route or executing as route problem which in this case SCCs are not helping that much since all the default SCCs that we have in Opensiv have this setting a low privileged escalation set to true to maximize compatibility with the applications so what can we do about this second risk so the Red Hat Security team is working on the creation of a more restrictive default SCC so that work can be tracked on the link on the slides and at this point if you want to drop privileged escalation you should create a custom SCC until we provide a more restricted default also you should avoid using set UID binaries and use file capabilities instead so instead of running as route for example just provide the minimum required capabilities to your applications and as a last resort you can configure it out of the rules that can lock this except V calls where the effective UID has changed to zero to keep track of containers abusing set UID sudo to become route on your applications right so now next next thing is how can a workload get access to use a specific SCC there are two ways that a workload will get access to an SCC the user creating the workload has access to that SCC or the service account used by the workload has access to that SCC for example and this is a common pitfall in Opensiv Red so when creating regular workloads on Opensiv deployments, stateful sets demon sets etc the pod is not created by the user who sends the deployment to the API so if I'm creating the deployment I'm not really creating the pod right so the deployment will create a replica set and the replica set will create the pod which means that in this case the only way of getting access to the SCC will be if the service account has access to it that our deployment or our workload requires any UID and the service account assigned to that pod or to that deployment actually does not have access to the any UID SCC so that pod won't run even if I'm logged as class should admin and I have access to any SCC it won't work because I'm not the one creating the pod on the other hand when you create a pod directly so you're connected to the Opensiv cluster using the CLI or using the web console that user might have access to different SCC so if I create the pod with my user then now I can get access to any SCC which basically means that even if the service account assigned to the pod does not have access to a specific SCC if my user has the pod will be able to use it so before moving on the common pitfall is that sometimes people try things like I'm going to create this pod and let's see if it works and the pod works because that has been created with a user which is class should admin for example and then when they move from a pod to a deployment and then try to create the deployment again with their user it fails and that's basically because at that point the user is not the one creating the pod anymore it's the replica set and the replica set will have a service account defined and that service account defined should have access to the SCC okay and now that we know how an workload gets access to an SCC next thing we need to know is how SCCs are ordered so if we have access to more than one SCC how opens it decides which SCC gets assigned to a workload so the first thing that will happen is that when we create a workload an admission controller will create a list of potential SCCs that can be assigned to the pod based on the pod specification and the SCCs that the user of the service account creating the pod can use okay then for example the pod spec says that the pod must run as root then any SCC that can be used by the service account assigned to the pod which allows the pod to run as root will be added to that list okay let's say that in that list we have three SCCs that allow a pod to run as root so now we need to order those three and pick one of those three so once that potential list of SCCs is created then the SCCs in that list will be ordered as follows so if the SCCs have different priorities then the ones with the higher priority go first if priority is the same the most restrictive SCC will go first and if priority and restriction level are the same then they will be ordered by alphabetical order so that's how you will pick one SCC so the one on the top will be the one that will be assigned to the pod so we introduced the concept of admission in the previous slide so now let's review what's an admission controller not in very detail but just a basic explanation so as you might know, Kubernetes has admission controllers which validate requests before they get persisted into ETCD in OpenC we have an admission controller that takes care of configuring the proper SCC on every pod in the cluster the code for this admission controller can be found here and then the workflow of an API request and how it gets through the different admission controllers can be seen in this diagram below so whenever an API request gets made it gets authenticated and authorized it will get through the mutating admission controllers which basically will mutate the request we'll see an example in the next slide then we will run the object schema validation since we mutated the request we need to make sure that it it can be validated against the schema and then we will get through the validating admission controllers which will run some validation on the objects and then finally if everything goes well it will be persisted to ETCD and at that point the controllers will start reacting to that change so the mutating admission controller have you repeated that workflow like a deployment or a pod without specifying any security context and you wonder why it worked so that's for example because the admission controller mutates the pod definition and adds the correct information for example the SCC admission controller will make sure that the pods run with the least privileges possible by default so for example in these examples below the number one is what we send to the API server so as you can see we didn't specify any security context and then in the number two figure this is what we got persisted to ETCD so as you can see we got the security context information added by default so this was done by the mutating admission controller so now we want to talk about common pitfalls with SCC ordering so let's go for them so let's say that you have a container image that's based on its metadata that's based on its metadata runs as root but in the pod spec you don't specify it providing that your service account has access to two SCCs and both have the same priority one that allows pods to run with UID 0 and another one that forces your pods to use and UID from an range your pod will be assigned to the later since you didn't specify the root requirement in the spec also keep in mind that cluster admin role has full privileges including the one that allows it to use any SCC so this is what we talked earlier about putting pods directly so if you create pods manually with the admin users keep in mind that you can face this issue last avoid assigning high priorities to your SCCs so your custom SCCs this might cause issues in priority decision if you create SCCs with higher priority than the defaults and you don't have the correct pod spec in place so for example if with OpenC we have any UID with a priority of 10 you don't want to create any custom SCC with a priority higher than 10 otherwise you can cause issues ok and now we are going to talk about some Linux capabilities in Kubernetes so as we have been saying capabilities in Kubernetes have some limitations at the moment but we are not using UID 0 on your workloads and that's why you have to use file capabilities at the moment there is an open issue to solve admin capabilities on the community which basically will bring admin capabilities support to Kubernetes and then we will be able to use admin capabilities instead of file capabilities and then last we will be helpful in the future this support has just made it to Cryo and it will take some time to be g8 but this will be also a useful feature when working with workloads that require UID 0 and also capabilities and with that we are done with the theory and we can get started with demos ok so let's get started with the demos so in this first demo we are going to see how a service account can get access to use an SCC by really granting access to the security context constraint to the service account so first thing that we need is a name space so we are creating this name space named SCCfun then we will create our service account which is named testSA1 next we are going to add access to the any UID SCC to the testSA1 service account and now we can check who can use the any UID SCC as we can see we have our service account listed here ok so that's a way that we can provide access to an SCC for one of our service accounts in the next demo what we are going to do is instead of running these commands we are going to create a role and a role binding that will allow a specific service account to get access to the any UID SCC so first of all we are creating a new service account which is named testSA2 and now we are going to create a role in this name space as you can see the role provides access to the security context constraints to the resource any UID and it allows the use of the perfect user ok so next thing that we are going to do is we are going to create the role binding and here in the role binding we are creating this use any UID RB and we are providing access to the use any UID role that we created in the previous step and we are granting this role to the service account named testSA2 and now if we can check who can use this any UID SCC we can see that we have the testSA2 as well on top of the test SA1 that we provided earlier so we can see that we have the testSA2 listed here and then in this last demo what we are going to do is we are going to see how SCCs are ordered in case that a service account can access multiple SCCs so first we are going to create a service account that we will use as a regular user that we can impersonate so it will be test user then we will add the edit role to this user test user so we can create things on namespace next thing that we are going to do is we are going to provide access to this user to the SCC restricted this is not really required because every authenticated user will have access to the SCC but since we are going to use hook and commands if the user has no direct access to this SCC like if it gets this access by an inherited group or something like that it won't sew up so in order to make things easier to understand we are going to provide direct access to the restricted SCC ok and now that we have this SCC what we are going to do is we are going to create a pod as you can see this is a simple pod which is using our test user and it's using a simple application image so now that we have the pod created we can run this command that will tell us with SCC will allow the workload to enter the cluster and in this case we can see that it will be allowed by restricted so we can create the pod as this user ok so we created the pod and now if we set the SCC that was assigned to the pod we will see that the SCC is restricted now let's do something different so now we are going to grant access to any UID SCC to this test user service account ok so now that we have access what happens if we run the SCC review again now we can see this pod will be allowed to enter the cluster by these two SCC's any UID and restricted so our pod specification doesn't have anything that will require it to run with any UID so let's check why any UID has preference over restricted so as we can see the SCC any UID has a priority of 10 while restricted has no value which actually equals 0 so now if we create the pod again so first let's get it deleted from the cluster and now let's get it created again and we will see that the SCC that was assigned this time is any UID because the any UID has more priority than the restricted SCC and this quick way of checking the SCC's for your pods instead of doing the old YAML and then you will get the pod name and a new column which is the applied SCC that will give you the SCC that is used by the pod and this concludes the first demo ok so in this demo what we want to show is how capabilities can be managed by SCC's so in this case we want to run an application that requires to sniff or capture traffic in the pod interface as you may know this requires high privileges ok so then I am creating a new namespace this namespace will I mean the application will deploy will be deployed through a deployment so we are going to create a service account so the service account will be in church of the deployment so we can assign permissions to this capable service account let's take a look at the deployment we are going to deploy an application control issue execute tcpdamp with the service account that we already created ok let's create the deployment and as you may expect there is an error in the deployment so we don't have permissions to execute tcpdamp to capture traffic first let's take a look what the SCC has been assigned to this application as you may know it should be the restricted it is the restricted one actually it is assigned to all the authenticated users to this service account so the service account has been assigned this restricted SCC another thing that I want to check is the user ID so as you may know the restricted SCC doesn't allow to run as root so the the user ID is not root in this case ok so next thing that we can do is execute the the application as a root user and in order to do that we need to create a new deployment this deployment is run as a user in the security context we are another thing that we need to do is assign any UID SCC to this service account because the restricted SCC as I mentioned before doesn't allow to run as any UID that we require so we will check that now the capable service account has two SCCs one with priority 10 which is the any UID so it has higher priority so it will be the one that will be assigned we are now executing again the modified application the participating but there is I mean we are seeing the same issue we don't have permissions so what we are going to do is we are going to access to the POT the debug basically execute the same container but with the bash entry point and in this case we are we are being I mean we are root but we are having we are not allowed to execute the POT so what we are doing now is taking a look at the capabilities assigned and we are seeing that these capabilities it's not I mean the NetROID is not included and that's why because those capabilities are the ones that are assigned by default to all to all the containers by the runtime as we mentioned during the presentation so the next thing that we need to do is we are going to create a new deployment and we are explicitly allowing or adding this capability NetROID to our application but this won't work out of the box because the NetROID SCC as you may know doesn't add any capability it actually drops one and it doesn't allow or add anyone I mean so the next thing that we need to do is copy this NetROID SCC and modify and create any one SCC I mean the thing that we don't have to do is edit and an SCC so we are copying the any UID SCC and we are adding the allowed capability NetROID here so allowing this capability we need to explicitly request it in the in the port aspect so now we are going to create again we are going to create the SCC we are going to add the SCC to the capable service account we are going to remove the any UID SCC because we don't need it anymore from the capable service account and now we are good to go I think we can create the deployment that we are requesting being userID 0 and we are requesting the NetROID capability and as we can see here the application is running we can access to the port all the capabilities that has been inherited and by decoding the capabilities we can see now that the CAB NetROID is included and our application is running successfully so with that ends our presentation