 Welcome, everybody, to this week's OpenShift Commons briefing. We're really lucky to have Hugo Rivera, who's one of our senior certification managers for Red Hat with us this morning, and I know I advertised this as the how to get your apps, containerized apps, enterprise ready and Red Hat certified. But it really is all about building a trusted container ecosystem, and that's what we're trying to do here with OpenShift 3 and the upcoming release. So we're pleased to have a great strategy here at Red Hat for making our containers trusted, and I'm going to let Hugo take it off and tell us all about that this morning. Thanks, Anne. Hello, thanks for joining. I'm part of the ecosystem team here at Red Hat. We work closely with partners in creating healthy, robust product ecosystems around our different platform offerings. And today I'm going to talk about our efforts around containers, which is obviously a technology of great interest to our customers and our partners. And based on customer demand for a trusted container ecosystem, we put together some offerings that we hope will be of interest to you. We're going to start with a bit of an intro about certification at Red Hat and clarified terminology. You might have heard about Red Hat certification in the concept of certified skills, so people that become a certified Red Hat system administrator, for example. But what you may not know is that we also have a large organization that works with commercial vendors to certify their products on the Red Hat platform. This is a collaborative effort. And what we aim to do is to assure our mutual customers that, first, the technology stack that they're going to deploy has been tested and validated. A lot of our customers like an open platform, like Linux, of course, and complementary technologies, but they want to make sure that the pieces have been tested together, and they're not going to be the first one paving a way for deployment. And the second aspect of certification is an assurance that the stack that our customers are deploying is fully supported both by Red Hat and our partners. So this is the principle behind our ecosystems. And I'm going to talk about what we're doing specifically in the context of containers. So applying the principles I just mentioned to container certification, the first question is why are we doing this? And from our perspective, is we all about trust? If you follow the news around containers, you might have seen a recent report about analysis of the Docker Hub. And a company called BanyanOps found that over 30% of the images in the official repos are acceptable to security attacks, things like Shell Shock or Harbleed. So this is a big cause of concerns for customers who like containers to love the simplicity for deployment, but they want to make sure that they're not going to introduce any security risk in their production environment. So what we want to do with container certification is to assist with these three questions. Can you guarantee the origin of a container? Do you know where it comes from? Can you verify that it's been tested on the target platform? Because the containers can incorporate a number of different runtimes. And it is important that a specific application runtime has been verified on the host oets and that we know for sure that the different pieces are working together. And finally, and most importantly, is this stack fully supported by all vendors involved? So containers are a great platform. They've been embraced by developers and getting a lot of traction. We want to make sure that we take that same technology to the enterprise space, much like we've done with other technologies like Linux and OpenStack. So this is an example of what I'm talking about. I use this PostgresQL as an application, but you can do similar searches on the Docker Hub. If a customer is interested or has a dependency for a commercial application that requires PostgresQL and they do a search, this is the results that you can find. Over 400 different repositories, different image names. It is hard to know all the processes that are produced in these images. So a customer may be wondering, who built this? And can I trust this? Does this have production quality? How was it tested? If I'm going to deploy a specific platform like Rehat Enterprise Linux, do we know if this has been tested or not target? And who maintains it? If there are bugs, if there are issues, if there are security vulnerabilities, do I know who to contact to get a fresh image? So we're trying to address these issues. And by the way, we like what Docker is doing. We work closely with Docker, the project and the company. But we understand that our enterprise partners have some very unique needs that we're trying to address through certification. So what do we do? That would certification, basically, we provide assurance that the container is coming from a trusted source. So we have established a relationship with the container developer and maintainer. We guarantee that the container can be safely deployed across Rehat Enterprise Linux platforms. And I'll talk a little bit more about this, but if you use the RAIL runtime, what we offer is package it once correctly as a container, and then you have a broad addressable market for your product. We're also sure that the platform is free from known vulnerabilities, because we check that the dependencies that are being used in a container image have not been reported to have a vulnerability issue. And finally, this is backed up by collaborative support. So we have a support relationship with the company that is behind this container. And if issues come up in production, we can work together to fix them. And you see here in the upper right hand corner, we have a certified technology logo. So for any of our partners who go through this process, they'll be able to use this product alongside with their application. Now, as I mentioned, the goal is to certify a partner container image and rely on a single application delivery model for containers across a whole portfolio from Red Hat. So we have enabled our different products to deploy containers. We did it a while ago with Rehat Enterprise Linux 7. Then with the release, a purpose-built product to run containers, which is Rehat Enterprise Linux Atomic Host. And of course, we have OpenShift that in its version three, it's all based on containers. So we're providing a broad range of deployment options which translates into a broad range of deployment targets for your own products. And the beauty of this is, the application is built and packaged in a standard way, according to best practices, then the same container image can be taken and deployed across all of these options. All right, so let me switch gears here and give you some examples. So I'm gonna escape this and open my browser. First of all, I'm gonna show you the user interface that our partners have access to. We offer to our partners a tool to handle certifications. And what is he here is the user interface. We also have a command line interface, but I'm showing you the user interface for managing certifications. Now you see that we actually have multiple certification types. So our intent is to have a single tool that can manage your different certification processes. So our hardware vendors use the same process to certify their hardware. We have partners working in the open stack space for infrastructure service and they use the same tool. And now we've added container certifications as another path for working with Red Hat. So you have some examples here that I've used submitting images. So I'm just gonna click on this and see. So basically, for this tool, the metter uploads both the image and the Docker file. You see an image here that we've been testing about 236 meg when it was tested and submitted. And then, I'll show you a report in a second, but basically the way the process works is you take an existing container and you upload it into a certification service from Red Hat. We have a set of automated tools that will introspect that container image. We look at what layers it has, we look at what the penises it's using, and we generate a report automatically that then you can go and check. So let me give you an example of the report here. So this is an example of a container submission that has a couple of failures. So there's a test to make sure a container does not have a security vulnerability. And in this case, the image that was made it had a failure. So I can go in and see what happened. And basically, and this is kind of a wordy, but it shows you that there's some packages down here that have some security issues. We analyze the content against our own security advisers from Red Hat so we can see that there's some security advisory that has the reported problems with this package. And so we hide the same issue on a few packages that are included in that image. So the submitter can go and review that advisory by this string and say, okay, I want to see what the problem was, and then they'll be able to take remedial action and update their image accordingly. There are a couple of other tests we're doing here. For example, we test that the base image is supported by Red Hat. So if you build an application that uses a different runtime, for example, Debian, Red Hat cannot really stand behind those libraries and that create a support issue for enterprise customers. So we make sure that whatever image was built to create a container happens to be an image that a base layer that Red Hat can support. The supported package in format here has to do with the right Docker version. So we make sure that the tools that were used to package a given container come from a version that is supported by Red Hat. And finally, we check that if you have Red Hat dependencies or layers that you're not making changes to those packages that come directly from us because if you do that invalidates our support. So for example here, there was a Red Hat provided file that was modified in this image and we report a file name, we report the RPM. So basically this has to be fixed because otherwise this wouldn't validate Red Hat supports on the customer end. In addition to the mandatory tests that give you a pass or fail status, we also add some notifications and basically we're letting you know that it might be more recent content or more recent version of certain packages that you use. So for example, this application is using a package called dzData, and this is the version and we're just letting you know that by the way there's a newer version of that package. You can still certify this is because you may have verified that that exact version is the one your application needs but we're letting you know that there's more recent content that you may want to incorporate. So that's an overview of the certification report that you get and after reviewing the errors and making the necessary changes you can submit your image again. I think I have a different image here of a certification has passed. So all of those four texts that I mentioned completed successfully and we have a warning here. In this case, just like I mentioned before, there's more recent content for that package dzData but again from our perspective is just a warning since this does not contain a vulnerability issue it's okay to release this image for consumption even though it was using a slightly older version of one of our packages. So that's in a nutshell, you know, a summary of the type of information that you get if you submit your container for certification and as I mentioned, you know, there's a user interface here that you will use to send your container over and then that report gets generated automatically. And I'm showing you the GUI, we're working on the command line option as well so that you can incorporate the same type of operations into your CI or CD environment and you can check for a pass file automatically and that's going to be coming shortly. So let me, I think it was a question on blue jeans. I don't know if I need to check for, all right. Okay, so I see there's a question about best practice building Docker images. So I'll get back to, thank you for raising that Pablo. I'll make sure I covered that in the slides. Let me go back here to presentation mode. Oops. Now, there's a topic closely related to certification which is around the distribution of those certified containers. And we have created the infrastructure to allow commercial software vendors to make their containers available for the broad audience. We are not making a red enterprise Linux container images available on the Docker Hub right now because it doesn't have the type of control that we need for our own software and our entitlements. So what we offered to our partners is a service called Rehecontainer Registry. And this is available for all certified containers and it's actually hosted an OpenShift which is the platform you all know very well. What we give you is the software that can handle the Docker distribution and within it, it takes care of managing the layers from the right sources. So our ISVs are software partners on the distribution of their bits and we are just providing the infrastructure and this registry is integrated with the certified catalog. So you would set up an account or OpenShift or you probably already have one and you will give access to the Rehat certification service so that once the image succeeds and get a pass report, that image gets uploaded automatically to that registry and is ready for distribution. So any customer of yours or any new potential customer that wants to get access to that certified image would just do a Docker pull from your registry instance and they would get access to those bits pretty much using the standard Docker commands. This is integrated with the Rehat certified catalog. So we have, let me go back to my browser here. We have in our customer portal, a destination where we publish certified products is divided into certified hardware, software and cloud because we cover a broad range of products. You can see that we allow customers to browse by software, hardware, they can browse by different ecosystems. We're going to open a new section for containers here where we can list all of those commercial software products that are packaged in a container format. So, and this is the prime destination for the Rehat customers to find information about the ecosystem around Rehat products. So this gives exposure to your product to a broad range of potential users and what we will do in the listing is include the Docker pull command. So you'll be able to, if anybody finds your product listing they can just copy the Docker pull command paste it into the system and with one line command it access to that application. What does this mean to you and why should you pursue this type of work with Rehat? And when I talk about this, I talk from both perspective of the software vendor and the customer. So if you're a software vendor, the reason for pursuing a continuous station of your applications is to achieve a greatly simplified application delivery model. So a simple one line command will now allow your customers to have your application up and running and you gain a lot more control over the application runtime because you're going to package it and configure it with exactly the right dependencies so that it's ready to go. The whole process of installation and configuration is a lot less error prone because it's greatly simplified. You don't need to tell your customers to go and look at a lengthy installation configuration guide. You're going to configure a product exactly the way you want it to be used and your customers are going to be deploying your product with exactly the right system dependencies that you tested in your own environment. And finally, it's a trusted enterprise platform. So, and Docker is a great technology but it is important to make sure that it's under control when it comes to vulnerabilities and security risks in the images themselves. So by having a formal process that you go through we're raising the level of assurance. And on the consumer side for our mutual customers they benefit from the application deployment just like we mentioned. The time to get applications up and running is greatly reduced and they get a better support experience, right? Less calls to support because they don't know how to install and configure. Less calls to support because they have the wrong dependencies. And if they do run into issues with production we have a way to collaborate and overall providing a better support experience. And again, it's all about trust. So, they have access to a pool of applications in a container format that they don't have invalidated on the right targets. And as I mentioned before our goal from Rehab perspective is to give a broad range of deployment options. Of course, open shift first and foremost because that's ideal environment for development applications at scale. But if customers want to deploy this in bare metal or in virtual machines, they can do it as well. And of course they can always pursue cloud deployments including public cloud with some of our cloud partners or their own private cloud. Now, let me talk a bit about the mechanics and the workflow that is involved in this. So, we have a program called Rehab Connect for Technology Partners and I'll talk a little bit about that. This is the destination where we offer the resources and the workflow that you pursue for certification purposes. We have tools to assist with the build process although this is really for people developing on other platforms. We have a container development kit that includes vagrant boxes and vagrant images so that you can create containers based on a Rehab platform even if you're developing on say Mac OS or Windows. We have the container certification steps that I covered already and then we have the distribution attained through the Rehab Container Registry Service. So, our goal is to guide our commercial software vendors through a simple process so that they can go through these steps and quickly get an application out for consumption. Let me spend a couple of minutes talking about the program itself. Rehab Connect for Technology Partners is a Rehab program for commercial vendors who have products that get deployed on or with Rehab platforms. So, you can be a traditional ISV, you can be an IHV, an OEM, but if you have a product that gets deployed alongside a Rehab product, then this is an important destination for you. What we offer is access to Rehab software, we have roadmap information, we have content for developers as well as for people conducting marketing activities and we're grouping content into zones which you can think of as interest groups. So, right now we have four zones, we have one specifically for containers, we have other zones for areas like metalware and open stack and through these zones, we present the workflow that I mentioned and kind of three simple steps, align, build and certify. So, come along, make sure we are aligned, make sure that this is the right technology that your product should be deployed with, build your application and then proceed with certification. Let me break to my browser again. Yeah, so this is the site Rehab Connect for technology partners, this is the container zone. So, as I mentioned, there are steps that you can follow to certify your application. So, we built that workflow here for you. We have information about why certify which covers some of the content that I went through in this presentation and they have a number of resources. So, there was a question about best practices for containerizing applications. So, we're posting our resources here. You have technical information here about containers, get started, portability, introduction to Docker and so on. And then we have things that you can download. You can request software access. So, again, if you're working in OpenShift, you already have access to a lot of these resources but for those partners working out of OpenShift, they may need to deploy some pieces themselves. We have the background boxes and other tools that I mentioned that help you develop if you're using other platforms like Mac or Windows. And then we have some other information here, updates, blogs, verification and so on. So, it's a good destination. I think it complements well what you already get access to within the OpenShift framework and we're working closely with the OpenShift team to make sure that all of the content is fully aligned. All right, I'll go back to the questions and thank you for tracking these questions. Let me finish with the slides and then I'll make sure we cover all of your questions. I've talked before about the ability to engage in collaborative support. We think this is one of the big benefits of engaging with us on certification. And the goal here is for us and our technology partners to collaborate to address support issues on behalf of mutual customers. So, without such an agreement, if a customer calls Red Hat and we believe that the issue is related to the application, we would tell the customer, sorry, we're taking it as far as we can, go and contact your application vendor or vice versa, a customer would call your company and you think it's a Red Hat issue. In the old days, you would tell the customer, sorry, called your operating system vendor. We have established a way for our support organizations to reach out to each other so that your support team would have direct access to Red Hat's global support services in vice versa. So, if you're in trouble shooting, we believe that the issue may be related to one of those certified applications. We can reach out to your company on behalf of a customer and you have the same privileges. So, again, this is great value for mutual customers. It reduces the finger pointing and it allows for a direct engagement path that would overall help increase quality of the whole stack. We used a multi-vendor support framework called TSA Net for this. So, if some of your companies are already part of TSA Net then you may already benefit from this, but if not and you decide to join our program, we will give you access to this framework at no additional cost. So, that's the end of my presentation, the end of the slides. My personal call to action is if you're an independent software vendor, you're probably already working with OpenShift and you're getting a lot of valuable resources there. If you want to know specifically about certification flow that I mentioned, you can reach out to me directly or join us through the containers zone at connect.redhat.com where we can get you started on the process. And if you happen to be an enterprise user of containers, we encourage you to ask your software providers to for certify containers and inform them that there is this process to the Red Hat that can help increase overall quality of the container ecosystem. And with that, let me... Let's flip over into those questions because there's quite a few here. Which is... All right. We go up to the top there. Okay. I think Chris answered Pablo's first question around both practices, but if you have any more advice around that. All right. So, see, when is atomic platform gonna be supported on public or in private cloud base on OpenStack? Is that question specifically about the atomic post? No, Chris, you had some comments there. Yeah, I think Katie and I addressed that one. You probably want to start with Michael Virgil's questions. These are the ones I haven't answered. All right. So how to certify versions handle customized re-responsibility. So this is something we're looking into. What we do today is we inform the vendor if there are updates, specifically their vulnerabilities. It is a vendor responsibility to practically release a new image. So, we depend on the software provider to update and re-certify once they patch the image. We're looking into ways that we can connect on the customer side and be able to complete the flow, if you may, to issue the same type of notifications to the end consumer of that image. So, but I think that that's not something that's fully implemented yet. So, at this point, we do have the workflow to tell the vendor to update the image and we rely on those vendors to take proactive action and notify their customers as well. I don't know if that answers your question, Michael. Yeah, it does. Thank you. So, if one becomes, like for example, if there's a vulnerability to one of the base images, does this website, does it hide it so that no one can pull it? Does it guard against additional? Right. So, we're looking into that and whether we hide it completely or we put a warning. And again, there are two ways for images to be found. One is we have a catalog that I show that it's a website where you can search and find information. So, we can certainly add a warning there that an image has a vulnerability issue. You will also be able to find these images doing a standard Docker search command. And I didn't talk much about how search works on the Rehab platform, but by default, if you're running on one of our many container-enabled platforms and you do a Docker search, you hit the Rehab registry first that includes all of these partner images. So, you'll be able to do, for example, the Docker search for, you know, I gave example PostgreSQL and see at the top of the results the certified partner images. So, in that case, we're kind of bombed by the Docker CLI and what information it displayed there. So, you know, we're working with the Docker project to improve what gets portrayed in the Docker CLI and be able to issue the right, you know, warning there. We can work with the vendor, and if the vendor agrees, they can pull the image completely from Docker pool. But again, it is their application. So, it's ultimately the vendor decision whether to pull it off or not. All right, thank you. So, Hugo, Pablo asked a good question or a variation on the questions that's been asked before, but is there a possibility or any plan to offer the review process for our enterprise customers so that they can verify their in-house images? So, the answer is, yeah, the satellite team is looking into this to use the same technology for scanning images. And again, right now, what we do is we look into our own security advisories, we're looking into areas like OpenSCAP and be able to do a direct analysis against, and I forgot the name of the site that gives you an oval feed for vulnerabilities. So, we're looking into expanding that offering and we're doing that in coordination with satellite team. So, that's, you know, that will be the vehicle for be able to do that type of analysis on the customer side in-house images. That's awesome. And Arcady has one more question here. After a containerized app is certified and some of its dependencies have new version, what happens to the support of a certified app? And Arcady, you're off mute now. So, if you'd like to speak to that. So, again, we're notifying the partner if there's newer content, but we don't think that in and by itself is recent enough to invalidate an image. We know that, you know, with containers and so many layers, there are different pieces that move at its own pace. So, you know, we don't expect people to be rebuilding images at a fast rate necessarily. I mean, some vendors may they have a good CI environment and they're able to consume updates automatically. Other vendors may be more cautious and just pick up updates, you know, on a case-by-case. Again, you know, it is really the vendor's own prerogative on what they consider a tested and validated stack. All we want to make sure is that it doesn't contain vulnerabilities. I don't know, Arcady, if that answers your question. Almost. The second reason is, you know, as underlying library dependency move forward, you basically, you know, you can recertify it and then you have now multiple version of the application. So is there a recommended kind of versioning control or, you know, what is the mechanism recommended for the apps? So we have some naming recommendation for images. And by the way, this is going to be an area of where we're going to see dramatic change because, you know, as I mentioned before, in the old days, there was a kind of a clean separation between the different layers and, you know, different vendors were revving at their own pace. Now you're combining everything, which is great for consumers, but it brings in this version management to the front. So, you know, ultimately, is the application vendor who, you know, needs to define a policy on how to update, you know, layer updates and how to cooperate into versioning. And they ultimately own the versioning mechanism and scheme for their specific products. We're going to be proactive with doing notifications on layer changes and something I forgot to mention. We are working on defining standard metadata for containers through the usage of labels so that you can include version and information in a somewhat standard manner by using specific label types. So you can include a label with, you know, the vendor name, the application name, the application version, and then, you know, revise that label as you issue new images. So, again, you know, we have some guidelines on how to do naming. We're not getting too much into versioning prescriptions yet, although we'd like to hear a feedback, Akadia, and see, you know, how do you think is going to impact your own product release cycle and what kind of things you'd like to see offered as part of the platform. All right, then. Are there any other questions that anyone might have while we still have Hugo on the line here and? I have a quick one. This is Michael again. Is there a, like, ISV administrator's dashboard so I can manage all my certified image so I can look at a dashboard-like view and just kind of see the state and status of my images and see which ones I need to take action on or is there reports that's generated available around aridine and the state and status of my certified images? Yeah, so the, you know, I show the user interface for the tool, which is kind of access, the kind of dashboard that you're mentioning. It gives you all of those certifications in flight and even across different products in case you happen to be a multi-platform, you know, provider. The notifications right now are done by email to the contact we have who submitted the application. We have a feature request to get that notification included in the dashboard as well to give you a single pane of control. But I don't think it's there yet. But again, that does the intent. We're all of the things related to your certifications, both completed and in progress are gonna be displayed there. Okay, great, thanks. All right, then. I'm not seeing, oops, maybe one more question here. That seems to have answered everybody's questions, Hugo. There's lots more information on the partners, customer partner site as well as Chris mentioned earlier. So on the connectredhat.com and under zones and containers there's a whole slew of informations and a couple of videos as well to watch. So I wanna make sure that if you have any questions at all you can feel free to contact Hugo or post them to the commons mailing list and we'll make sure we hook you up with Hugo and the appropriate folks on the certification team. So thanks very much Hugo for taking the time this morning and this video will be posted shortly. Yeah, and I included my email address in the chat. Diane is hrevero, that's H-R-I-V-E-R-O at redhat.com. People wanna contact me directly. I recognize some of the voices here on the Q and A so happy to have that discussion individually but if anybody wants to offer feedback again, this is an exciting time and opportunity for us. A lot of room for improvements and refinements. So, interesting hearing what you have to suggest. All right, thank you very much everyone for attending and we'll see you next week. All right, take care. Thanks.