 Okay, so good morning, everyone. I would like to welcome you in our first session today here in G202. I would like to remind you two things. First, we would like to sign in for tomorrow... I hope it will be here. Tomorrow I think you could do it in D-hole. The main room D-105. Second, don't forget to vote and write every session. You can use the data application or mobile as well. Okay, today first session has a title understanding OpenShift security context constraints. In this session, in this talk, we will explore the various steps to execute for enabling the required permissions on selected OpenShift spots. We will explore the correct usage of OpenShift service accounts default SCC. See our templates editing with real examples and demonstrations. This talk will be presented by Alessandro and Federico from Red Hat. Thank you. Hi everybody. My name is Alessandro Iquiel. I work as a solution architect for Red Hat. I basically transition between my previous role as a platform consultant. So basically I was at the customer's site trying to figure out and working with Red Hat technologies, helping customers to integrate in their environment, working with third parties, applications, software, etc. And now working on OpenShift, OpenStack, CloudForms or many cloud environments. This is my colleague Federico. Yeah, I'm Federico. I'm an architect for Red Hat. I work on some customers with Alessandro and with other colleagues. And we try to introduce OpenShift and OpenStack to this customer. This is quite challenging sometimes and this talk explores some of the challenges we are facing the customer. Okay, so if you are here, I imagine that you know something about OpenShift. Basically it has an enterprise version called OpenShift Container Platform. The community one is origin. And so what is OpenShift is a platform as a service. So you care about services and its technologies. It's all open source. So you can serve its source code on GitHub. It's container-based. So for now it runs Docker container but hopefully it will run more runtime containers in the future. It's Kubernetes-based. So there are some kind of things that share with the underlying layer that it's Kubernetes. And it's development-oriented. So you can configure automated builds. You can build your container from sources and so on. You can also add many users you want. Also you can, for example, define policies and isolation for your user for every container and so on. It has a nice web interface. Okay, maybe you don't care but many customers want it. And it's also an easy way to understand and monitor your current infrastructure. It has integrated registry. It means that actually you can download or build your container and work also offline. So no internet data at all. You can also configure high availability. This means that actually you can set the many replicas you want for your container, for your pod, and OpenShift will care about it. It has also integrated metrics. So basically you can look at fancy graphs on dedicated web interface. And OpenShift loves Git, finally. You can use Git. We will see in how different way we can use it for building containers, also for building your application and so on. So all cool but where is the start button? The fast way, the easier way to run OpenShift on your laptop actually is through the OC cluster app command. OC is the OpenShift client that actually lets you integrate and execute command on your OpenShift infrastructure. And so you have only to start and download this client and run this command with the proper option. And it will download a containerized version of OpenShift. Configure, check the Docker client, Docker version, import some kind of images. And finally it also install the basic services of OpenShift like the registry for storing your Docker images, your container images. Installing the router that actually let you contact your internal container from the outside of the platform. And finally make some other things like importing templates, creating a default project and a default user. Just for clarity, when you say download in the client you mean you are connecting to the existing cluster or you are deploying the system. No, you use the package manager including your operating system basically on Fedora and DNS. You are deploying the cluster on your system. Yeah, we are deploying on our laptop and this is a containerized version. So it requires at least a Docker install and properly configured. Yeah? Just a sign that is it possible to create a cluster with a valid cluster for less input? Yeah, yeah, you can do that. Not so easy with this kind of start. But yeah, you can do it. Yeah, yeah, of course you can do that with the advanced installation. There are Ansible playbooks that can manage that. On the bigger installation. So you mean at least one master then multiple nodes. In this case, there are only one containerized version on your laptop. I suppose actually you can do that. Yeah, you can do that. I don't think it's quite easy with OSQL as a wrap but you can access to all the configuration files or you can do it manually, not with Ansible script. You can do that. Okay, so what are the security context constraints? By the way, OpenShift gives to its administrator the ability to manage a set of security context constraints. And a security context constraint basically allows an administrator to set some kind of permission on the running pods on your infrastructure. A pod is basically the smallest compute unit on your OpenShift that can be composed by one or multiple containers. An SEC allows an administrator, for example, to run privileged containers all by configuration, set capabilities that a container can or cannot do, set Selenux context, set the user ID that the container will use to run, set also a set of allowable supplemental groups that the user that will run your container can be allowed to use, can also help you to define a container with a read-only file system and also, for example, control the usage of volume types. You can define whatever in a security context constraint if your container can mount NFS or can mount GlacierFS. Basically, okay, security context constraint. I just want to run my container. So we will take, for example, the WordPress container just for, yeah, you know. As I told you, we are working at customers and the customer maybe has played with Docker and just want to run the containers that he downloaded from Docker and want to try it on an OpenShift installation. And we are engaged for short-term engagements running POC and we want to make it work at once on OpenShift. So we will see the first workaround we can do in order to run almost every Docker container on OpenShift and then we will see how to refine the architecture in order to have a better approach to the containers. And in this talk we chose WordPress. While in OpenShift installation you already have WordPress already integrated as a template in the OpenShift installation which runs with correct privileges and permissions. But in this, this was just an example how to run any other container into an OpenShift environment. Okay, so just move on. The first thing, we have to set up the summary website for our container, chosen container. In this case, we chose the WordPress container. Okay, so actually it needs a DB basically, a SQL DB. You can find this information basically on the page or just surf Docker app, for example, searching for your container and then look at what kind of required environment variables it needs to run, okay? From these environment variables we understand that actually we have to set up a MySQL MariaDB server, okay? And so we just run an OC in your app, MariaDB, with an environment variable as you may do on Docker itself. And OpenShift will care of searching for a container named MariaDB. Actually you will search first on its available image stream that actually is a sort of images available inside the OpenShift registry. And then it will start configuring its deployment config. The deployment config is a set of configuration for your container, okay? And finally it will start it with the very strong password we defined, MySQL, okay? In the environment variable. MariaDB itself will look for an environment variable named MySQL root password and it will start the container, okay? Stop talking, just run my container, okay? So imagine that we want to run our WordPress container. We have all the prerequisites set up for our infrastructure for the container itself. So we created an OpenShift project we deployed a MariaDB container and so we start a new application, a WordPress application. So in this case, again, OpenShift will look in the all the available registry for a container named WordPress and finally it will run with the WordPress DB host, MariaDB. This is the name I gave to the MariaDB container. And then the default user, root and the very strong password, MySQL, okay? As we can see, just from the output there is a warning, the image WordPress run as root so you may not be permitted by your cluster administrator. But, okay, who cares? We just take a look at the running container and there is no WordPress, okay? It actually is in an error state so we can also take a look at the logs and we can see that actually it could not bind to the address, maybe to the port 80 because it's a reserved one and it's also unable to open logs. So just for, yeah, ouch, just for troubleshooting what happened to my container? We can first take a look at the definition of our container, of our pod in an OpenShift language. The described command actually let show us a sort of summary of the configuration so we can see that the security policy is restricted, okay? And debugging the WordPress container with the other command, OC Debug, actually it will run a copy of our container, okay? With the same namespace, with the same security context and give us a shell, okay? So we can troubleshoot and we can inspect the actually behavior of the container and we can see that actually running the ID command we can see that the default user, the user assigned by the OpenShift cluster is not the root. This is explain us why in the previous log we have could not bind to others because actually it was not running as a root so the standard user cannot bind to the port 80, okay? And maybe it cannot also open the logs because it has the right permission, okay? So solution for your lovely container not only for WordPress, for any container you may experience problem with and so you can edit the restricted security context, okay? We just saw that this is the default one that was assigned by OpenShift or maybe we can use a dedicated security context. You can find it on any your installation of OpenShift because it's shipped with OpenShift itself or we can rebuild our container through the Docker file giving to that container the ability of running as standard user, okay? So first option, the worst one, editing the restricted security context. First of all, we have to access to OpenShift platform as a system administrator, okay? In my case, I just look in with the system admin. This is a standard default way with the OcGlass therapy which it will show you the instruction at the end of the start but basically you can get a list of the security context with this common, OcGetScc, okay? Basically you try to get a list of the preconfigured and so already shipped with OpenShift available security context and we can see that we find at the end the restricted one and also the annual ID that we will inspect in the next slides. So first of all, we will take a look at the restricted security context and you can see in the bold, the most important option of this security context that's actually not allowed to run of privileged containers, okay? But it's not our case. We don't want that WordPress to be a privileged container. It's available for the groups of user, system auto-intigated so basically any user of your OpenShift installation and it has also a set of required drop capabilities, okay? This means that actually inside of your container you cannot execute some of this system code. After that, you can see the run as user option. The run as user defines what kind of user your OpenShift installation could assign to the running container for let it run, okay? And finally, as we saw in the security context description you can also define the type of volumes that the container using this restricted SEC code mount, okay? Yeah? So the must run range is the UI inside of the container, right? Basically you could define a range also of ID not present in the container itself. Our OpenShift doesn't know what kind of... It doesn't expect what are the user configured in... In fact, it assigns a very random... Okay, you see? UID, okay? You know right now the UID that is assigned to the user inside container has nothing to do with the outer world. So there is no, like, if you want to do NFS... Yeah, of course, of course. That user could also not be... Could not have the right of writing on some location. For example, it cannot access to the logs, for example, okay? So we so start editing. Remember, this is the worst. The worst solution, but, okay, we start editing the restricted one. So we change the run as user type from must run as range to run as end, okay? Let's actually let our pod to run. So, okay, it works. Are you sure? Yeah, okay, we see that actually the container is running, but... Take a look at logs. Actually, we have a lot of operation permitted. And you can see that from the output there are a lot of complaints about the set GID. Because maybe there is some script inside the container that tries to change the ownership of some files, okay? So, basically, this container is not allowed again. And finally, yeah, we should see also, yeah, maybe... No, okay, okay, no. In this case, out again. We go also to remove the dropper capabilities, okay? So basically at the end, we see that we have no more errors, okay? So, we remove the set UID and set GID, drop the capabilities. Is that because Apache wants to drop frames? No, it's because we will inspect also the Docker file of WordPress container. There is something called Docker entry point. That actually, in most cases, is a script that prepares the run of the final command. So, in this case, maybe, in the Docker entry point, the developer just puts some Cheyenne or Chey group in common for editing the ownership of some files. Maybe the HTML or PHP file of WordPress, okay? So, removing them, okay? So, you see, there is no more required dropper capabilities set GID or set UID. The errors disappeared, okay? No more errors. Create a root, test it, and you see the WordPress installation page, okay? Yeah? So, when you change it to run as any, did that make it a root, like a vector UID root? Yeah, yeah, you are root. It uses the root user, yeah? And so, there are no more errors accessing the logs, for example. But it also has some limitation. In fact, we have to change the set UID and set GID, drop the capabilities. So, what are the implications of what you have done? Yeah, yeah. You are just allowing any container on your OpenShift platform, because you are editing a restricted security context that is global on your OpenShift installation. It's not for this container. It's for, yeah. So, it's a very, okay? That's an easy thing to do, right? You just allow every container to run as a root and do the set. In fact, I said this is the worst one. Yeah. So, set UID, I just looked up set UID again. It's not for chmod, because chmod is a different syscall. That's for, that's for drop-prims. Yeah. For, like, root to change. Yeah, yeah. Yeah, yeah. Yeah, no, it's not chone. Chone is a different one. Those are different syscalls. Set UIDs for running process. It's chones for files. It's a capability. I trust Daniel. Yeah. Okay. Okay. So, moving on to the second solution, okay? Using the AnyUID security context. Basically, we just recap the list of all the available security contexts. We choose to use the AnyUID, and we will see why. Just because, okay, it doesn't allow privileged container, and it's enough. But it has a run as user type of run as any. So, like the edit we have just done in the previous security context. It doesn't have also the required drop capabilities that our laws are complaining of. Okay. So, how to use it? Yeah. We are using now service accounts, which are mainly a way to define non-personal user in OpenShift. As you can think, not every operation is run by human in OpenShifter. So, there are service accounts that are commonly used, for example, from APIs to execute some operation. For example, for some external tools in order to access the OpenShift APIs from inside the containers themselves. If they have to reach some APIs inside the OpenShift environment. Or if you can think about any operation you run, you usually don't run directly to the OpenShift infrastructure. For example, when you create a deployment config, you're not running that deployment config by yourself, but you're simply instrumenting the controllers, which are the authentication, the replication, and all the list of the controllers that are running the operations to do the thing you're asking the deployment config. So, the service accounts are those accounts that runs the operation for you. And we're using that in this case to define which service account runs the operation. Okay. So, first of all, we move to our second project. We create a service account. We saw that in previous definition, the service account is related to a project. So, we create the WordPress service account inside the second project we created. We are now also a system administrator for our OpenShift cluster. And so, we can manage the assignment of a user to a security context constraint. Basically, we are seeing with this command to add the just created the service account, WordPress service account to the security context. Any idea. Okay. So, we are just saying that the WordPress security service account can actually use the Anyuid security context. And so, just looking at the output, so the description that we saw, we inspected before. Now, under the users enabled for the Anyuid security context at the end of the slide, we saw that there is the WordPress service account. Okay. So, first of all, just, I don't know if you remember, I just told you that executing the OC new app actually let OpenShift search for your Docker image on configured registries. Okay. And also, with that command, it will create a set of configuration, like the deployment config, okay, for running that container that will hold also, for example, the environment variables we define it. Okay. You see that? Okay. The WordPress DB host MariaDB, WordPress DB password MySecret, WordPress DB user root. Okay. So, we need to edit this deployment config to enable the usage of a service account. So, basically, we insert the service account option defining the name. We don't need the long form because the service account is related to the same project. Okay. And finally, we can take a look also to the summary with the OC describe command and see that actually it's also defined as a service account. This is the edit we just done, okay, with the OC edit command. So, taking a look at the logs of the new running version of our WordPress container, it actually is not complaining anymore. Okay. And taking a look at the description, summary of our new pod, WordPress pod, just created, we can see that actually it's using a security policy name, any ID, instead of the restricted one. Okay. So, just because we, in this slide, you can see that actually just because we have the run as any type option and we don't have any of the dropper capabilities that we saw the errors in the WordPress container errors file, the container is just running fine. Okay. Easy. Okay. So, moving to the third solution, yeah, the best one, maybe. So, why rebuild the container image, first of all? Yeah. What we've done is from a customer perspective, we run a POC, so we run which has the containers that we work in using maybe the restricted security context, the SCC, or maybe using the new ID or maybe creating another one and using that. But we have a running platform at the end when we want to put something in production, we will try to tell the customer that the correct approach is to build a correct doctor file, maybe because we will not be the OpenShift cluster administrator, we will let some developers to build the images and we should not at all grant wrong permissions like root permission running on the containers, that is what we did in the previous two examples. And so, we're working directly on the containers. Yeah. It's also because maybe when you let OpenShift search an image for you, also if you use an image that you trust, you are downloading basically that image from Docker app on any other, maybe not trusted registry. So, first of all, you cannot trust by default third party containers. So the easiest way is first of all search for the current Docker container you are using, maybe on Docker Store, Docker Hub, whatever you want. Looking for the GitHub Docker file, you will find always this file if this is an automated build Docker container on Docker Hub or Docker Store, whatever you want to name it. And make the edits to the Docker file. So to the source file that let you build the container and edit and upload it somewhere. So, we are inspecting the default WordPress Docker file. We'll see that actually it runs from a base image PHP 5.6 with Apache web server. And we see that actually the final command is Apache 2 foreground. So you see also the entry point that maybe is causing us the previous error we saw. And okay, we made some edits you see in both. We first of all edit the Liston instruction, Liston configuration, moving Apache configuration from Liston to 80 port to port 8080. This allow us also to run Apache with a standard user, not root user. Okay, we also expose the port 8080. And then we add write permission to the group. Basically the group is Google data. I don't show you all the boring stuff. You saw that you can run or see the bug and basically inspect the running container without any problem. So, another edit I have to insert to let not our container to fail is to remove the bash script run. This basically remove the fails of bash in case of any of the command of the script fails. So basically you go running, not caring about, for example, complaining on changing permission or whatever. This is a dirty way but a fast way to do something. And finally I've uploaded the edited Docker file and the entry point edited to my GitHub account in a brand new project. And I pass this kind of GitHub project to the OpenShift. OpenShift will scan and we clone this Git repository, inspecting from inside of it. And it will look at the Docker file. And finally it will configure for you also the build config that actually let you in some automatically way the build of your final container. The other option are the same we have just used in the previous example. So basically it will create a build config you see here at the end of the slide, the output. It also configure the deployment config and finally a service. So we attach also an empty volume to the VAR HTML to let the container write somewhere the WordPress PHP file. Edit the deployment config, adding for a supplemental group. This is actually needed because if you look at the edit we have done, we are adding right permission to the group. So OpenShift will choose for a user. But we are actually defined also as supplemental groups. The 33 is actually, you can see it at the end of the slide, represent the boovoo data group. And so finally we have a running container. We have rebuilt our container with some edit, some clean, some dirty, no matter what. And you have your container running. We create a route and get the code. They have a cheeky comment. It's still running on what OS is underneath that in that container image? Out time or? Oh, it's Debian maybe. So I rebuilt all this on raw with software collection. I did exactly what you guys did. I calculated the official for Docker except that built it on software collections 2.4. Usually this is the way we do that at the customer site. Because on RAL7 you are attached to the Red Hat registry, Docker registry. And so we rebase basically for the customer, third party containers or also some other vendor that actually sells software to our customer and rebates on RAL. So if you have more time for doing that, just rebase it, install the proper software and let the container run with your chosen software. I did exactly what you guys did except I ripped out the guts underneath and made sure the software collection was RAL plus I modified the WordPress. I even used a W to get everything but then I verified it. It's all in a built on RAL software. This is kind of the approach for the person who really knows what they are doing. This is what you need to do for production. Well, this is what we as people who develop production-ready containers actually do. But this is not something that a developer who is going to consume OpenShift is going to do. And we can't tell them, you know what, this is the container but don't trust it. Go have it inside and go for the best. If we deliver something which is coming from us, we say this is how it should be. So now this is how it should be runable by them as is in their OpenShift to accomplish their goal. So the question is, can we do something else? Not modifying, not hack things, but if the container is an infrastructure container that really needs root and you can't hack it around, is there a plan to do something about it? We are not currently involved in the product itself, but I think that actually... This should be coming right. Yeah. Actually... I think the main... At some point in the future also you will be able to as an administrator to set up a new project. But I think the first thing is to build a community. So enable the developer or the user or whatever to use OpenShift. Right, I find that the customer does want to do this. They do want to do all the production guys. They don't want to just pull stuff. No, but if I'm building a community, I want to do it in the OpenShift online. In the OpenShift online, I won't be able to run root containers because I don't have control in the OpenShift online. So as a developer, as a consumer in the community, how can I do something? Give me a tool. That's kind of what I'm looking for. It's going to happen in the OpenShift online case. It's somewhat of a sad thing because the least common denominator which means that you have applications like WordPress that require root... Yeah, I want to do it wrong. Make it easy for me to do that. But anyway, the username base is being turned on for OpenShift. We're going to compromise some local securities on that. The biggest problem with username space right now is that username space actually works fairly well in the operating system except for file system support. So when you run username space, you actually change UID from 5000 to 0. It's how you run the UIDs on the disk and don't get changed. So if you have a UID 0 on the disk, in fact 1000 of the username space is 0. If you look at that file on the disk, it says it's basically identifying it. So you can't do it on a lot of taxes. It's going to be looking at container images and things like that. All the stuff that's been built up over the years is going to break the standard username space. What Darker's done at this point is that they've remapped one username space. So you'll end up with all of the content. So Dark Dark is defining something called Dr. Roos. It's going to be, again, with a CPU ID of 5000 per case. Now when they pull down any image, they show UID 0 to 5000. So it looks right in front of the container. But it gives you an isolation between the two hands. It's very, very funny. It's the same route. It does protect the host a little bit. Because you're no longer moving the host. But you have the same UID for every bit. It's running UID 0. It's going to have a second UID. Is he letting it pull down a little bit? But I like to think of everything. Except for I don't like it. As he letting it pull down, everything's fencing down. So there's a package called Shift-Fest. It's actually proud of Google Cloud. If you've seen anything that talks about Google Cloud, they say they can run regular container production with user namespace. The reason they're doing this is they're using a thing called Shift-Fest. Shift-Fest is basically a file system that you can mount on top of an existing file system that will change the UIDs from the process to one view. So Shift-Fest will take a UID 0 on it. It doesn't change the 5000. If you're going to use a namespace that has 5000 after 0, then you look at it as a good Shift-Fest. The good thing about this is you're shifting UIDs in one direction and you're shifting UIDs in the other when they come together. Everything goes wrong. The problem with that Shift-Fest right now is incredibly insecure because it's writeable. So when you're running your Shift-Fest by writing down UID 5000 and writing something to the Shift-Fest, you get Shift-Fest to 0. Now if the process is running at 5000 writing on real disk, UID 0.5. What we're doing working on internally right now is we're setting up that file system so that we don't like that you wouldn't be able to write to it. We're fixing up all the pattern. They've got rejected upstream originally. So you'll have a read-only version that you will now be allowed to write UID 0.5. And then you put it overlay over the top of it. So we've got delaying the directory with the Shift-Fest. There is a content that you'll write and we'll get rid of that Shift-Fest. And Shift-Fest is limited to like one directory. You mount it on the other. It's not limited to any place. It's like a bind mount to the Shift-Fest. So that, right now, where we have an experiment, they're working really well. We're looking at it within a month going up to the next level, which has never been repeated and just for the father, he's the name of it, he's the reviewer of the patch, so we're going back to the bottom link. We're going to the stages of the reviewer view before it gets as close as it can come. We're going to be doing, so getting it into the upstream kernel might be a problem. I think we're doing a pretty good job of figuring out the security end. Hopefully within six months we'll have it. I think that might be it. Thanks, Daniel. OK. You used the SCC policy to mask content as a non-loop. So I would allow anyone of us not to loop, but it didn't work. It was a non-numeric idea. OK. Yeah, you can allow that. Actually, you have to, by the way, in some way edit then the Docker file to let this standard user, the non-numeric one, to map to a regular user. It just looks at least cosmetic. Yes, there are both in order to use user one, to use user one. There is a way to define how you create images for OpenShift. The user that's injected, visually injected in the images, it's a part of the group. So where your process wants to write, or you allow new permissions to those they have to make new versions. So if you're interested, you can go for OpenShift but around the user, you are in the same group always. You are a new group always. You set right permissions for the group. What is your process then? Why? Because everyone is a group and everyone is still sharing the permissions like for any other group. And we are editing the Y0 issue all over again, and then we will do the Y0. So this is exactly how you do it. But even if you set the permissions you set it correctly, you wouldn't let the process to do it because the policy is not met. And also you describe the application control or you could say the mastern as non-route, because the non-numeric IDE is still some I don't know everything that was supposed to be fixed in the origin but we have tried versions and we are trying to start. One more question? Yeah? I'm trying to visualize this scale. I have a few hundred apps and they have been multiplied by the environment like dead stage and test, dead stage and prod. I imagine I would have been more towards the end of the test, right? Do you guys have any recommendations for how I would keep those texts and policies like organized from a high level? Is it like other ownership admins that don't actually supply them? You could do that using the groups basically. So you allow some groups to use some SEC for example, more flexible and then some others to use only the restricted one by environment. No, I think you can manage that by groups, not by environment itself. So if the groups are associated to different environments, so you will achieve that. Could you repeat please? Do you feel that everything that's inside of you is not individual and different from what I have before? Oh, okay. Yeah, it's just because if you remember I don't know if we can go to the restricted one Yeah, you see somewhere this one, you see that actually we have a group with system authenticated. So OpenShift basically will find out which kind of security context to use at runtime and choose the one that in this case is allowed for the system authenticated. This link? Okay, this one? Yeah. Why is it different with all the posts? Is it something? Ah, okay, no, no, no. It's used by, it's different for the various posts. It's choose in a range. In the default range of OpenShift. What? Is it just one? No, it's in a range. Is it okay? Yeah, it's configured somehow. Yeah, you can configure it. Yeah. Okay, so thank you very much. Thank you. It's just become a photo. I didn't want to say it from everyone, but I was a Swiss doctor back to me, so I prefer to demo only rail and software connections not like alpine and you know what I mean, just like if you're going to show them the rebuild it then show them the rebuild it all the way. That's my only positioning. It's also our position. By the way, the meaning of the talk is to enable how much of the I know and I get it, it was a range. I'd almost add a fourth one where you rebuild the bottom stack too. You could probably just graft on the last piece. I have all the code, it all works. Yeah. Everything. I'll share it with you guys. I just created, I just bought a domain in my WordPress Dupload on which I put on guitar as many as default templates or projects, so keep in touch. Yeah, I will. I'll email you guys. Thank you. Thank you so much. Yeah. Yeah. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Let's go. Good, good. I'm not going to use the slides, but I'm going to use Google slides. So we have a marketing team, I'm going to go straight. So you don't have to wear a microphone on you. I'm not going to wear a microphone on you. No, no, no. I'm not going to wear a microphone on you. We're waiting for 7. I don't remember. What time is it? It's almost 7. How much is it per hour? It's about 40 minutes. 40 minutes of the time? Okay, 40 minutes of the time. Okay, 40 minutes of the time. Come on, come on. I'm going to try to get out of here. It's true that there should be someone who collects the questions, because when you ask someone who asks you, you don't understand what you're asking. I don't know, but that's a problem. Do you know what the question is about people who ask questions? You're sitting in the back. It's okay. It's okay. On the other hand... On the other hand, when you're such a faulty person, like the man in RMS, who was working with him, I'm definitely on his side. And then he said that he doesn't want to live a single life. I'm definitely on his side. He's a very beautiful English man. I understand him. I understand him as me, but I'm not a native person, so it wasn't a classic question. I don't really understand anyone. I see. And I'm on his side. Please do speak English. I don't know what to say. There are no consonants in your words. I was once again in the presentation when Borac shouted at people not to sleep. So I have to go to sleep in my presentation. So I have to go to sleep. Borac is in front of 500 people. Yes. Who is that? That's Rotec Ruzhol. That's Skyboros. Skyboros is in front of 500 people. I think that's a good idea. Maybe it will be better. Now I have a redhead. Maybe Skyboros will be better.