 So we're actually close. We finally got the long list of the factors that was broken. All of them are free. Like the most recent one, the instance that we've seen. Can I start? I mean, I don't think that's a true representative. Can I start? Oh, one minute. Oh, I see. We've put it too much back. Well, we'll see. I'm going to read the main. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Good afternoon, everyone. My name is Chris. Chief technologist for North America on the west coast at red hat. at Red Hat, and I've been with Red Hat for about 12 years, working with strategic partners and customers, primarily in Silicon Valley and the tech and entertainment verticals. And so today's discussion, a security state of mind, enabling continuous security for DevOps with Kubernetes. I'm gonna go through some of the drivers behind DevOps, also in terms of DevOps, how can you enable DevOps with containers and Kubernetes and the security implications of containers, as well as if you have time at demonstration, some of the basics of Kubernetes, how can help you with managing security at scale in your container-based environment. And so does anybody recognize what this is a photo of? It's an assembly line, yes. It's actually the Tesla automobile assembly line. And the reason I show this is that there's a digital transformation happening across all different industries. Just take this as an example. And the business is really putting a lot of pressure on companies to really innovate quickly and to deliver capabilities rapidly to the marketplace. And certainly, no better than Tesla, they have revolutionized the automobile industry. And not only are they automating the production of these vehicles with software, but software for the first time is enabling these vehicles to be better over time. For the first time, I can buy a car in six, 12, 18 months down the road. I can get a software update over the wire to improve the zero to 60 time better battery efficiency or update the applications in the center console for autonomous driving or turn-by-turn directions. And so, huge fundamental transformation and competitive advantage that they're having over the rest of the industry because they're able to rapidly innovate quickly and deliver capabilities to the marketplace. And what happens to an industry that rests on its laurels and stops innovating, right? This taxi industry represented by San Francisco here in this graph is a perfect example of what can happen. You know, the San Francisco taxi industry pretty much have monopoly on point-to-point driving and ride-sharing in San Francisco for many years and they stopped innovating. Well, Uber and Lyft came along and totally transformed the user experience, but also they fundamentally transformed the business model because they were able to leverage real-time data of their customers and their drivers and match drivers to riders and also dynamically scaled the pricing to encourage more drivers to enter the market as well. And so they fundamentally had a competitive advantage. And so even if the San Francisco taxi industry came up with a mobile application, they were still at a disadvantage to Uber and Lyft because they were using real-time data to be competitively ahead of their competition. And so as you can see, the ridership in taxis drop by 65%. It's even gotten a lot worse last year. They filed for bankruptcy, the San Francisco yellow cab and they were the largest provider of taxis in San Francisco. And so there's a lot of pressure on IT to keep up and not become the bottleneck. And so you're seeing a transformation in how applications are developed, the architecture that they're used in terms of microservices, also in terms of how applications are delivered in containers, and then also where those applications are deployed in terms of private or public clouds. And so one of the main hurdles that IT has is that it's very difficult to move software, encompass some of the move software from dev test into production. Many customers I talk with, they say it takes four, six weeks to get a single word changed on their public-facing website. These are large companies that you've heard of, may use their applications on your mobile phone. And one of the key things that they have is organizationally, they're organized in silos. They have the developer team, they have their QA team or operations team all siloed off, not collaborating. And as a result, they've evolved with their own processes, their own technologies, making it very difficult to move applications through the pipeline of dev test into production. And security is certainly an afterthought, usually reserved for operations. And so dev ops has evolved and has gotten a lot of publicity and popularity because it breaks down those walls and it's really people process and technology. Bringing together these different disciplines of dev QA operations in even the business unit as well. So more mature dev ops organizations will actually be tightly aligned with that business unit and collaborating with them and bringing them into the team as well. And then adopting new processes such as CI CD to enable rapid building of your software and rapid deployment of your software. And it's not just about how many times you can release your software per day, but it's when the business needs that new innovation, IT is able to deliver it for the business right away. And that's how IT becomes a strategic differentiator for the company in terms of being able to deliver on that innovation to the marketplace rather than being viewed as a cost center in the organization. And certainly, how do you enable this? Open shift based on Kubernetes and Linux containers is an enabler for organizations to rapidly roll out this next generation I call software factory. Intel, their competitive advantage over the years has been their fabs, right? For a software enterprise, how can you be a differentiator? You need a next generation software factory that can rapidly and efficiently roll out innovation and new capabilities for the business. And so, Andy Grove speaking of Intel talked about how only the paranoid survive. In this context, it was back in the 90s and he talked about how there's this point in time, a strategic inflection point when there's a massive amount of change in the industry. And for them, they had the pinion bug which was a massive crisis point in their history. And the company has the option of either adapting and thriving to the marketplace or falling by the wayside. And I feel like the IT industry is certainly at that point in time with this huge transition to DevOps, to containers, and to public and private cloud as well. And what do you do about security, right? Security is an end to end process. It's not just about production. And when you look at the DevOps, there's some changes and some implications to secure that we're gonna talk about today. And the key point here from a DevOps perspective, security starts in terms of the people, the process, as well as the technology. And it starts in development, carries into task and into production. It's not just a production issue or an operations issue. And so let's talk about continuous security. Today, we're talking a little bit about OpenShift, Kubernetes-based container application management platform enabling really the automation of the build of your containerized-based applications as well as the automation of the deployment of those applications. Some early adopters of DevOps have cobbled together their own pipeline with automation scripts maybe it's Puppet, Chef, et cetera. And what has happened in those organizations is you have the developers coding infrastructure pipeline code. It's very inefficient in a waste of their time because that's a time taken away from them developing new innovation, new product features and capabilities that matter to the business. How do you free up your developers from coding this do-it-yourself pipeline to embracing something that's out of the box automated and enables you to rapidly deploy this innovation for the organization? That's what OpenShift is all about. Enabling your developers to be efficient, enabling them to hit the ground running and deploy containerized applications and move it through the lifecycle of DevTest into production at scale. And so here's the typical CICD flow in a containerized based environment. Typically you have your developer checking in their source code to be your GitHub repository. Then once it's checked in, triggering a build, right? And that's an automated build putting that artifact into the repository creating that based on a build image that's reproducible and inconsistent every time you build it. And then once you generate your application in a containerized format putting that into a shared image repository, right? The whole principle here is you build your application once in development and then deploy everywhere. You don't rebuild and reinvent the wheel in your test environment, right? Get rid of that silo instead break down those walls move that application from Dev into test as is put it through its testing cycle resolve those issues rapidly provide the feedback to the developers and then promote that through the lifecycle into production as is, right? So everything that goes into production has been tested during the build process, right? You build it, you test it and then you deploy into production. Don't go into production and make changes that have never been for this test cycle, right? And that's a real change in the DevOps process. Build once and then deploy anywhere. And here are some of the implications around containers from a security perspective that we'll talk about many areas that need to consider the security implications around, you know the content, the container image. What about the build process, right? How do you incorporate security scanning as a part of your build process? You're gonna build it once, scan it after you build it and then deploy knowing that it's past the security check. Also a registry of where you're storing these images, right? Are you gonna have enable your developers to go out to the public cloud and download any image or you have a private one? How do you deploy security updates and security fixes in a container-based environment? At the end there, container hosts, right? How do you manage security patches for that host as well? What are the security issues there? Do you wanna be aware of? Network isolation, right? How do you ensure isolation if you have your dev test in production environments in a OpenShift or Kubernetes-based environment? What about storage, right? Containers aren't just about new applications that are stateless, right? What about your existing applications that you wanna containerize that have persistent data requirements? How do you manage security for that? And then how do you control access to this platform? The APIs, everything's being API-driven. Well, how about controlling who gets access and the ability to create these clusters to have access to the data? And then also monitoring and logging capabilities to help you with security for your clusters at scale or across the federated clusters as well. How do you manage those? And so there's some work coming up in the Kubernetes community to enable those capabilities. And so let's go into some of the details. First off, the basic principle around containers, the basic flow is to build, ship, and run. You build your container based on a Docker file, right? And a Docker file is similar to a make file in C language. And of course, you wanna version control that just like you would if it was a programming application. And it's a very simple, easy to read syntax. And then once you build that image, you wanna build it once, you wanna then be able to share that image across all your environments. And so you will put it into a registry, whether it's public or a private registry. And so this is a repo of all your images, right? And the enterprise, primarily people are using private registry, so you know where it was built, what's in it, right? Whether it's gonna be trusted or not, you wanna sign those images too. And then you wanna be able to deploy that image, whether it's physical, virtual, private, public cloud, or in your dev test or production environment, right? No more rebuilding or having things done in a unique way in each individual environment. Have it consistent and repeatable and have developers build on a production-like environment from the get-go so you don't have unique issues. And so first off, what are some of the basic principles around building your Docker file and best practices? So treat it as the blueprint, right? You wanna have a recipe for how you build all of your Docker images or your container images, right? You wanna be able to reproduce that. Just like in a physical system, you may have a kickstart file for how to build that Linux host, right? Don't log in to your container image and run commands to configure it because no one's gonna know how to redo that, right? When that person goes away, how do you rebuild that image? What changes were made to that image? A version control the Docker file, right? Store it in your source code repository and use versioning. And then when you're using an image, just be explicit with the version number. Don't use latest. Be very explicit so you know what you're getting. And be mindful that every time you put a run in the Docker file that it creates a new layer. So you wanna be efficient with how you're doing this so that your images don't get out of control and become very large. OpenShift itself has some built-in capabilities to manage that image size and to reduce the layers by using base images for you and doing some cleanup for you. Also, let's talk about content security, right? So container images, they allow you, you know, the Linux containers allows you to package any application. Similar in the Java world, you have your standard format there and you have your standard runtime. Likewise, in the Docker world, you have your Docker file and your Docker runtime. However, in the Docker file, you can actually run C, DHB, Perl, Python, any language. It's not just about Java. But a Docker image, it pulls in the dependencies of that application. So it has everything it needs to run inside that container image, right, in the user space. And so, one of the things you want to be mindful of is what's it pulling into that Docker image? Let's take a look at the second one. That's the Java. It pulls in the JRE, bash, glib, c. And what you may not be able to see, there's a little triangle and there's a number inside that triangle. And in the JRE, the triangle says 66. And what that number represents is the number of security notifications that there have been since RUNL 7.0 was released for the JRE. So what does that mean? It means when I'm pulling these images down, I need to be aware of what security issues are in that image at the time I pull it down. But I also need to be thinking, what's my process for checking on security issues for this image on an ongoing basis? I would have had to address 66 different issues over the life cycle of RUNL 7.0 as of the time this slide was put together and it's many months old and there's certainly a lot more since then. So what inside the container certainly matters. And another best practice is as you're implementing continuous integration, continuous deployment in your DevOps environment, you wanna incorporate security. So this is a Jenkins pipeline. It typically has different phases where you're committing, you're doing a code review, unit testing. What about adding a phase that does a security check of that Linux container image? So once you build your code and then once you automate the building of that container image, you wanna run a scan on that image to see if there are any known security vulnerabilities. If there are, you wanna flag that and potentially stop the pipeline or at least flag an alert. And then secondly, you may wanna scan that image to see if it complies with your security policy, right? Are out of date services enabled and running in that container? Are certain directories created that you don't want there? File permissions, et cetera, are they accurate? And so those are the types of scans you wanna incorporate as an automated process so that every, with the philosophy of build once, the plenary, after you build it once, check it and then you know you can put it wherever it goes, it's already passed that security check. And you may ask, how do I go about doing this automated scan? There are many tools out there. One is an upstream open source project called OpenScap. This allows you to not only scan container images for security vulnerabilities as well as security policy within a container at rest or running, right? So if you have a container that's running, you can scan that or if it's not currently instantiated, you can scan the image on your NFS or your Gloucester file system. And it also works with virtual machines and physical systems as well. And essentially what it does is Red Hat or the distribution that you're working with provides a security guide for that operating system with the standard security policy settings. And then it has a checklist you can either check or uncheck those particular criteria if you wanna enforce those in your environment. An example may be like set password minimum length. And it also can scan for the RPM CVE alerts as well to see if there are any positive findings within that container as having known security vulnerabilities. And OpenScap is a set of tools. It also integrates with the upstream project form into manage security at scale. And it generates reports if you need to audit or have compliance regulatory standards you need to meet. And it also has remediation. So if it finds particular issues in terms of it having an air in terms of a security policy, it actually can automatically run a script to rectify that issue. Maybe it's disabling FTP or maybe it's setting the file permissions or directory permissions properly in that within that image. And so that's OpenScap. Also another best practice is to treat containers as immutable, right? What does this mean? It means separating your application code in the configuration as well as the data, right? And so that's an ideal state is you wanna have that nice separation of your application. Those usually make the best case of what applications to containerize, but more and more features are being added to support any type of application. And an example of this when you have nice separation is in Kubernetes they have config maps which basically allow you to set environment variables or you can use secrets which are encrypted so you can pass passwords. But keep those data, that data outside of the actual container image, so it'll store in the image. Instead use things like objects like config map which allow you to use key value pairs to pass on data to an image and make it dynamic without having to store that data statically in the image. Also some of the work that's being developed right now from a Red Hat perspective is around image sign. So in a RHEL atomic host which is the container optimized spin of RHEL7 it provides a containerized, a lightweight container based OS. And there's a lot of development to be able to sign images so that you can then check the images to make sure that they're intact and they haven't been modified. And so that you can trust that image to run in your environment. You don't have to worry that it's been hacked. And so there's a lot of work from a Red Hat perspective being done on that in the 7.3 release. Also a container build process. So in a traditional environment today most enterprises have admins responsible for the core build. They're using a kickstart file to generate that RHEL image or sent us or whatever distribution you're using. And then your middleware team is typically packaging up the J2E server or whatever application platform they're using in a tarball. And then you have your application developers packaging up maybe their Java and a war file. So right there that goes back to the real challenge with DevOps that's overcoming is that you have these silos. They're not talking the same language. You have kickstart, tarballs and war files and each organization doesn't know about the other. They're using different tools, processes and it's hard to collaborate creating a lot of friction amongst these team members. Well one thing that Container does is it breaks down those walls and now all three organizations are specifying their application in a Docker file. So now they're all talking the same language. It's the sad minutes responsible for the OS. They specify the definition of that base image in a Docker file, the J2E middleware team. They now specify the J2E server also in the Docker file and they can leverage the base image. This is sad minutes defined. And then lastly to deploy that application they can define that within the Docker file as well. Right and so now it's very modular and using the same tools and syntax. And so what this means is then you have kind of a supply chain in this inheritance where the new application leverages version one of the middleware and version one of the core build. I as a application developer, I don't wanna pay attention or spend my time keeping track of OS core build security issues or even middleware J2E issues. And with this model, you don't have to. Right because I'm inheriting what the other teams have done in leveraging that. And within the OpenShift solution, I can subscribe my images to what's called image streams and if there's ever an update. So if I've written an application that depends on core build version one, there's ever an update to version one will automatically be notified and it can optionally trigger an automated rebuild of my application with the update of version two which maybe addresses a particular security issue. So providing a lot of efficiency around security in that model. And so let's talk about these security implications around the ship step. So register security. Red Hat did an analysis of the public Docker Hub registry where you get tens of thousands different images that you can pull down. But at this point in time, when we ran the analysis, 64% of those images had a medium or high priority known security vulnerability inside those images. So the message is here, if you're in operation spokes, be aware of what people are pulling down into your enterprise. These are things like Hartley, Poodle, Shell Shot type of security issues. And so what can you do? The best practice is around private registries. Setting up a private registry, OpenShift automatically deploys a registry on top of the Kubernetes environment that you can leverage in your OpenShift cluster. There's also a standalone OpenShift registry that you can set up as well. And then you can also have a hybrid environment where you have private registries but if it's not available in the private registry, it can then look into a variety of public registries as well. And then the last phase is the runs phase. When you're running and instantiating that container image as a process on your physical, virtual, private, public cloud. And so one of the different things you wanna be aware of is that in your CISCV environment, you wanna be aware of where you're pulling that image from. So you may wanna have a private registry, you may wanna have registry in your production environment versus your dev test environment, but then just move images from one registry to another. You can certainly do that by copying them. So that's a best practice there. And of course, you wanna incorporate that security scan as part of the build process. And then also in terms of continuous deployment, OpenShift adds automated builds to Kubernetes and then Kubernetes provides automated deployments. And so you wanna be able to have visibility into the progress of your builds and your deployments. And so OpenShift provides pipelines to provide that visibility to your developers or admins. And then also provides the ability to easily deploy the container images into production. And then also deployment strategies. So Kubernetes enables continuous deployment and it has a lot of deployment strategies that allow you to address the issue of how do I update and patch my containers at scale? They talk about one physical machine could translate to maybe 10 to 20 virtual machines. Well, multiply that by 10 if you move to containers. How do you address security at that scale? It needs a lot of automation. And so Kubernetes, no, we should help you with that. In this case, you have the ability to do rolling updates to your environment. So you have version one deployed onto your environment. Your developers work on version two or the next version to address that issue in 1.2. And with Kubernetes, you can do an automated rolling upgrade by updating each individual pod. And here I've deployed it to one pod and I can test it out. If I have confidence that it's working and it's not to break it, I can then increase it to two thirds and then till I have 100% of my environment. And what it's doing is it's updating the load balancer, taking out the old version, putting in the new version into rotation. And it's automating all that for me so I don't have to write scripts. I don't have to manage the networking. I don't have to manage pushing these images, et cetera, making my deployments very easy. And I could also roll it back if there was a particular issue. I can also test out security patches without going all in and I can see what the impact may be. So let's say I have version one installed and I want to develop another version and see what the impact would be. So 100% of my traffic is currently going to version one. Well, I could also deploy out into production version 1.2 and then I can route some of my traffic to version 1.2 as well as version one and see, hey, is there an issue with one or the other? And so here you can see my A.V. testing. I could deploy 80% of my route to version one and I had a 25% conversion rate, maybe on my click through. And then I want to see what the impact of deploying version 1.2 was and here I could see it's gone up to 35%. So I wanted to validate that before I fully commit to that new version. And so OpenShift allows you to dynamically adjust the load balancing so that it routes 20% of all traffic to the new version and 80% to the old. And I didn't have to write scripts to that and handle that all automatically for me. And also, what about the hosts that these containers run on? But what are some of the best practices for my hosts in my Kubernetes OpenShift clusters? Well, first off, don't run your containers as root. It's not necessary, right? You wanna run it as a non-root user because if I run it as root, then they could have root to the underlying host as well as all the other containers on that particular system. Also, you wanna go to a model where you're not SSH-ing into your containers, right? Have everything that you need accessible via a service API, right? That other habit of SSH-ing into check logs, et cetera, set up a log service. Also, Kubernetes has names, spaces for networking, for example. I can set up network isolation for my dev test in production environments across the same underlying physical infrastructure. I can provide production-like environment to my developers easily, but at the same time have isolation from a security perspective. Also, you wanna define resource quotas, right? So you don't have to worry about the noisy neighbor, right? Don't let one container's over-consumption impact the quality of service of the others. Enable logging, be sure to have a process and tooling to apply the security around it, as well as security contacts and set comp filters so that you limit the capabilities of the process that's in the container. So it doesn't have full access to all the kernel capabilities. Filter that out. And so security context, this is the operating security settings, UID, GID capabilities, et cetera, apply to a pod or a container. So OpenShift provides the ability to define a policy for your security contacts and deploy that. And so we talked about content, builds, registry, deployment container hosts. And so now I think I have about 10 minutes. And so I'm gonna go into a demonstration to show you some of these capabilities. How many have used OpenShift or Kubernetes before? How many have used Docker? Okay, wow. All right, so I'm gonna show you OpenShift. And I already have the, oops, bring that on the projector. So OpenShift has a command line and I am using a wrapper called OC cluster to that command line. It's getting angry at me. So the nice thing is, really simplified from a developer perspective, I don't know, we have some electrical static going there. So I think I just go like this. Looks like we have a short. So the OC cluster command allows me to rapidly bring up a cluster on my laptop. So this is an old MacBook that I'm using. And nice thing is it really shows you how lightweight OpenShift and Kubernetes are. And so I'm gonna bring up, so what it did is it went and instantiated a cluster on my laptop. This is an easy way to get familiar with Kubernetes and OpenShift is to use the OC. And so you can see it's, what it's done is it set up the cluster. It's installed a registry to store my images. And then it's also set up the GUI. Okay, and so I'm gonna get one step further this time. And I'm gonna bring up the web console. And so here I have my web console for OpenShift. I logged in as my developer user. One possibility was to try to reduce the resolution of the output. Oh, the output? Okay. But I'm not sure if it will work. We're gonna... Yeah, but it looks like it will not. I don't know how much. I think that some program is this EPRS. Do you think it's the resolution? It might help. Okay, we'll try 720, is that it? Try that. There we go. Yeah, yeah. All right. It's so far. And so, I'm gonna go ahead and delete these. If I can deploy AB. Oh, it looks like that may have been the problem. Is there a certain resolution? Let me try another resolution. Yeah, I didn't see anybody have any, unfortunately, I was just going to show a demonstration of the ability to automatically build your application. Once I have that container built, I can easily scale up, scale down, and I can also roll out the next version. And then I can also do things like A-B testing, so I can do 80% of load, 20% of load to version A versus B. And then I built that image in Dev and then now I can just take that image and move it into my test environment, my production environment, all on my laptop, without having to rebuild and kind of move that image through the life cycle. Go ahead now. The questions. Okay, the deployment scenario doesn't actually differ much from what we had in the past, maybe, and all that stuff. Question is, okay, how can we propose handling counter deployments or blueprint testing in real life when you have applications that depend on the background, for instance. So we have two versions, but the new version needs, like, I don't know, database changes or something like that. So this is one thing, and the other is, does how a certain shift suddenly support Kubernetes updates? Sure. So the first thing is, you know, how do you handle your data store? So I've seen folks leverage the container application platform with their data in a couple different ways. Some, you know, don't have the option of moving the data into a container platform. They leave it on their physical and virtual infrastructure, right? So they have some sort of manual process to keep it in sync, or they have some automation, maybe Ansible, outside of the platform to kind of synchronize and orchestrate that. Others have moved their data into a container and deploy it with their application. So in some cases they're creating a pod, which a pod can consist of one or more containers. And for some applications it's tightly coupled, whether it's latency or just they scale up and scale down together so it makes sense to put it in a pod. And so then they treat it as a single entity with two containers within that pod and then they upgrade, downgrade, and together. And then you have separation where you need to just orchestrate. I think for instance, it's natural that the database is deployed together with the new version of application and then test it, right? Then you are sure that it's so capable of collection. Then you apply the same for the normal database that I believe will be outside of the business. And also they're developing so they have backwards compatibility, right? So there is AIP for those of you in the field so that you can have a few installable sets? Yeah, so like Petsets, I think it's been renamed now. But those are for more static IP, static type of deployments. But that's different than the upgrade process more about the implementation. And I'm sorry, the second one about upgrade. Yeah, so there's an upgrade process with an OpenShift to upgrade the nodes, to upgrade the master in your environment. Some folks, they do their upgrades by deploying a totally new cluster but it just depends on... I've seen some real world where that's, every time they upgrade they just deploy a totally new cluster. And so they've really automated the movement of their configuration from one cluster to another. It's not bad actually if you're going to be sure that you don't lose production. Right. I think that's the thing and those pretty good developments, I guess you need quite a bit more time to decide if the new version doesn't have any faults. The OpenShift that you're providing the capabilities to, you know, enhance noise at all. So you would have different levels of monitoring. OpenShift really provides more of the infrastructure and the container level from an application perspective to monitor like the click-through rate and things like that. You would use your traditional monitoring as well. So that would replace it but we do augment it with, you know, the utilization of the resources, etc. for a container or at a host level. And we provide centralized logging with elastic search capabilities to search through those and we gather those logs and you can also plug it into like slump if you want to search those logs. And so we provide centralized logging. That's a great question. So how does OpenShift support essential logging? Do I have to actually employ or configure mining software applications or do I have to? No, so that's a great thing. It has logging and monitoring capabilities built-in. When I was doing that OC cluster there was a monitoring command-line option as well as a logging one. And it would deploy the logging or the monitoring services on top of Kubernetes. Yeah, that's fine. But the application that is deployed on Kubernetes needs to log somehow to the service that is. Oh, so it's standard out? Standard out, yeah. So how would then come to statuaries in the last search? Well, how do you handle them? Yes, it was normally from standard out. If there gets logged into the last search, you would get by 30 records in the last search, and there's a lot about that. OK. Any other questions? Which point is it put out, standard out? Sorry, standard out. Standard out, then take. Basically, you can imagine use for build, run, consult, and doing this kind of work for customers. You have to try to put the data into a special place after the customer in the group, the customer you know, which may be coming from standard out. Imagine KPMG comes to see your work. How you will do this, what business of the service? Yeah, I don't know. I'm just going to take a look at it. OK. So what's the next one? What's the next one? How do you provide access? Well, what's the next one? I don't know. Here? Yes. Okay. Okay. Here. Here. Here. Here. Here. Here. Here. Here. Here. Here. Here. Here. Here. Please. Please. Please. Please. Please. Again. Please. Attendant.