 Well, hello and welcome, everybody, to this OpenShiftCommons.gov SIG Talk. It's one of a series of briefings that we do every week, and this is the kickoff for the .gov special interest group. So we're really pleased today to have Jason Callaway, who's been working on the OpenShift Compliance Guide and has been working with a number of customers and deployments in the federal government sector on FISMA compliance, and he's going to share with us the work that they've done to create the Compliance Guide and open up a conversation with the rest of you about maybe contributing to that. So without any further ado, Jason, take it away. Awesome. Thank you very much. All right. So let's just dive in. You know, normally when I think about compliance, the first thing that comes to mind is driver's licenses and sitting in a DMV, because that is also sort of a form of a risk management framework, and it's a useful analogy because none of us like it, none of us really like going to the DMV, but at the same time, I don't think our lives get better by getting rid of driver's licenses and just letting anybody do it. So it's sort of an unpleasant thing, but a necessary thing. And it's a little bit more than that for those of us that work with the U.S. government because it's actually the law. There's this thing called FISMA that came in this E-government Act in 2002, so you can actually look that up and find it in the United States Code. And it has sort of a spaghetti chart of implications. So FISMA has been amended a bunch of times from the original Act that was passed in 2002. It identifies various federal agencies that are responsible for implementing and enforcing this stuff. NIST is really the main one that we typically think about, and they've published a number of different special publications that affect that, sorry about that. So apparently I'm not able to mute my phone, that's awesome. So we have the risk management framework itself that comes from NIST Special Publication 837. We've got template SSPs that you can use, that's fantastic. And then FIPS 199 itself describes how to actually implement that risk framework. The security controls that get implemented come from this monster document called 853, special publication 853, and that's got a total of about 1500 individual security controls. And then there are some other guides that you might have to comply with such as FIPS 140-2 that does a lot with which crypto algorithms you're able to use, and it has a certification process, and we can talk about how Red Hat technologies comply with that. The way that you typically automate these things is with an umbrella of technologies from NIST called SCAP for the Security Content Automation Protocol. We have an open source implementation of many of those standards that come from open SCAP. We have another project called the SCAP Security Guide that has a bunch of XCCDF profiles to implement things like the STIG, which is itself an interesting bit of dependencies there. So the SSG actually is upstream of the US government configuration baseline USGCB, which informs the STIG that is published by DISA, and that's a coordination effort with several different agencies there. If you're working in DOD or in the intelligence community, there are still separate authorities that you have to worry about, and then there's some terminology that's changing. We used to call it the certification and accreditation process. That document's been deprecated in favor of a new risk management framework. It's called ANA Now for Assessment and Authorization. So it's a big mess, and typically a barrier to being able to get on with doing the work that you want it to do. So normally in this process, you create a great big spreadsheet of all these different security controls. You down select that to the ones that apply to you because there are numerous non-technical controls in here. And NIST deliberately did not label controls as technical or non-technical because depending on your project, you may have a technical way of implementing that and you might not. So it's designed to be very flexible. But the implication of that is that it puts more work on the end user who's actually writing the system security plan and taking that body of evidence through the ANA process. Gosh, I apologize about the phone there. Okay, so moving on, we have published this OpenShift Compliance Guide that is sort of this is sort of a very new effort and it's not typically done. Normally and in fact, if you look at the FedRAMP document which is sort of around, good grief. Very sorry, hang on one moment, I'm doing a briefing, I'm going to go terribly sorry about that. So we've taken a lot of the work here that we've put into doing this ANA process several times and we've open sourced that. We want to be able to get some reuse out of this because we find that we've done this a number of times and we're constantly going through that same work. So while this is sometimes done in sort of a sensitive environment where the body of evidence itself may be classified or just sensitive, we've taken those things that we're able to share. We've open sourced it and we've put it out in sort of a framework that we think will be a little bit easier to scale and collaborate. We call that the OpenShift Compliance Guide. This is actually hosted off of GitHub, the visual interface here is done with something called Read the Docs which is a really cool tool that we can dive into a little bit more and sort of break down what we have in these different sections here. The reference architecture is really important and when you're going through the ANA process, one of the kind of primary things that you have to get through is just educating your creditors on what it is that you're trying to do and particularly with new technologies like containerization, that can be a challenge. We went through this whole thing once before with virtualization and there were many sort of learning curve moments there where previously but before that every single information system as an example was physical and had a barcode on it, an asset tag and could be tracked as an asset. So once virtualization became a thing and it wasn't possible to put a physical barcode on a virtual machine, that tripped up a lot of people in that older C&A process. So now with containers, again, there's more to learn about. So having a reference architecture and this CONOPS, this concept of operations, PreFab is going to help you get through that process more quickly. The SCTM, the security control traceability matrix itself is the core of this whole project that's actually a very large spreadsheet which is sort of our canonical source of truth because while you generate a body of evidence and a system security plan and it's all nicely formatted, every time I've done this, it really comes down to sitting with your creditors, having a spreadsheet up on a projector and going through the things that they care about line by line. So that's why we made that sort of the core of the project. That spreadsheet gets parsed and we procedurally generate what you see on the read the docs website. And that's handy because you can just send somebody a PDF of that if you want to sort of jumpstart that process. But the spreadsheet is what you're going to end up at anyway. In that spreadsheet, we identify who is responsible for implementing a particular control. So in some cases, it might be a physical access control, a non-technical control that we sometimes refer to as the guys with guns controls. So that's going to be your physical security officers that are being sure that only authorized people are actually able to get into the building where your information systems are hosted. Typically, that's not an open ship thing, that's somebody else. So there are different roles of people who implement these things. The customer responsibility matrix makes it very clear what an open shift consumer has to implement in their SSP. And then we've done a lot to automate this with Ansible and we're well down the road to being able to sort of have a turnkey, press button, get reference architecture deployment. We'll talk about that. We're not quite there yet and we really appreciate help from the community. So just to go over this reference architecture a bit. We did this based on Amazon web services because that's where we've done a number of these open shift three deployments now and it's what we knew. It doesn't need Amazon, this could work on any infrastructure. And because OpenShift runs on top of RHEL and uses Docker and Kubernetes, all it requires is RHEL. So that means we could be doing this on VMware, it could be on top of OpenStack, Azure now. So there's very many options. It's just that for this one, we happen to use Amazon as a reference architecture. We would like to generalize that but we didn't have the time to make it really general so we stuck with what we knew. So we have here a very conceptual diagram of all the different components that go into this. So this is something handy that you can give to your accrediting engineers to kind of review what that architecture looks like. And then we have a more kind of a more abstract view here of the different system types and how those interact. All of this is in the compliance guide, by the way, but I thought it might be a little bit easier to go through slides. So this one is a pretty important one. A lot of times you'll spend a considerable amount of effort documenting the data flows that go into your whole project. It's done for you here down to the port level and identifying which system types require different ports and how that data flow works. We also have a conceptual diagram of how the build process goes for when you actually spin up an app. And this becomes really important when you're dealing with folks that might not be familiar with OpenShift or just straight up might not be familiar with how Docker and OpenContainer image format works. So being able to show them this and how you take application code from a Git repo and then that gets pulled into our source to image or S2I process, then that will create an app image and stick that into the integrated registry. This kind of helps break down that knowledge barrier to be able to get to this. Now when it comes to how you actually implement FISMA compliance, there are baseline controls around what we call the CIA triad and that doesn't mean typically what you think it means. It's not in this case referring to the central intelligence agency but rather three different types of areas of concern around confidentiality, integrity, and availability. Each one of those has a baseline low, moderate, and high setting. And we designed this guide to help you achieve the FISMA high deployment. Now as you might imagine, having high ratings for confidentiality, integrity, and availability is more difficult to achieve than simply a moderate setting. And one of the things that you have to worry about at high is encryption at rest and in transit of your storage. So this became sort of a more complicated thing than we thought it would be when we set out to do this work because one of the things that OpenShift offers you is persistent storage through the PV and persistent volume and persistent volume claim process within Kubernetes. So how do you scale that and how do you get encryption at rest and in transit there? And there were a number of ways that we could have hacked this and we ended up deciding on this architecture because it gave us the best balance of bang for your buck with your underlying compute resources, in this case Amazon EBS volumes, and then where we were actually doing the Lux encryption. And one more note here. We wanted to use Lux because it comes out of the box with REL. It's a free to use tool. Some government agencies have a preferred provider of storage encryption. So if you have some other thing that you've got to use, you could certainly sort of plug and play there and use something other than Lux. That's just what we chose here in this particular architecture. Before we go on to kind of digging more into the controls, do we have any questions in chat about the reference architecture? We've got one question from Sean Wells on the data flow side. Do you have anything that shows where the encryption is being used for node to node and internal to external communications yet? That's a great question. I don't think we have that documented, but that's something that we should capture. So this brings up an excellent point. When you're looking at this guide and if you find that it doesn't have something that you would find to be useful when you're going through your ANA process, let's just open an issue on GitHub. This is an open source project and we have the opportunity to collaborate here. So that's a great opportunity to open a GitHub issue so that we can get that into the guide. Or if you want to make it really easy, you could simply write that in yourself and issue a pull request. We'd love that even more. So the only other question so far is they were looking for labels for each of the slides. But what I was going to say is if you go to the OpenShift Compliance Guide, read the docs page that the URL is in there, you can find almost all of these images that he's using in that, I think for all of them, are in that guide at some point. And I'll try and cross-reference them when we post the video next week. Other than that, you're moderating right along. Do you have a URL for the GitHub repo for issue requests? Sure do. So if you use our tiny URL that we had back here earlier, OCPCG for OpenShift Container Platform Compliance Guide. In the upper right there, there's an edit on GitHub link. So that'll take you directly to the page for that particular section that you're looking at. And then anywhere from there, you can just click on the Issues tab to be brought to that. I'll just pop that. I have that link and I'll pop it in now. So if you want to go motor on a little bit more. Excellent. Continue. So given the guide as it stands today, this is the breakdown of controls and who's responsible for what. So of the total of about 1,500 controls in NIST 853, we find that about 660 of those are technical controls or at least controls that may be of interest to an accreditor who's going through your body of evidence. In some cases, like with the guys with guns controls, typically they don't even bring that up. So that's that might not even be of interest. But for other things like. Passwords on the BIOS for the underlying host system, that will fall into whatever I as you're using. So in this case, we're using Amazon EC2. That's something that they handle and they probably have their own SSP for that. So we hand that off. We inherit that control. So this is the breakdown. An open shift consumer or a tenant in this landlord tenant model, then would be responsible for tracking 73 controls, whereas if they were, say, running their own open stack and building their own applications in there, they'd be responsible for everything up to and including that I as layer. The security control section, we're missing some things. And we've got a couple of janky workarounds right now. Ultimately, they need to become RFEs and get upstreamed into open storage and make it into the enterprise-grade product. The way that we work around some of these things is sometimes, as I said, a little bit weird. One example would be the way that we do security banners. So there's no easy way in the OpenShift tool right now to add some kind of security banner saying like secret classification at the top of it. The way that we get around that is we just wrap the web console in a little bit of JavaScript that adds like a 10-pixel banner at the top, that has the proper color and the right stuff in it, and then we resize an iframe to actually hold all of the real web console. In this particular case, we have this already written and we're going through a downgrade process to be able to make that and classify and put that into the compliance guide itself. If sometimes that can take a while, depending upon how motivated our government sponsors are to actually get it done, we could just rewrite it. So this is an example of one place that we don't yet have what we need in the guide. We have some sections that still need some work and this would be one of them actually being able to add that security banner. Sean and I had a great conversation last night about a couple of these other requirements and one example would be like the notice and consent click-through that you typically have to use when you're in one of these environments. So that normally when you log into an environment, you have this say a DoD warning banner where you agree to monitoring and you promise that you're not going to use the thing, you hit OK to accept. In many cases, you're able to inherit that control from the workstation baseline for the agency where you sit. Many of them have workstations that that government agency manages. They have they have their own set of click-through. So we found that we're typically able to inherit that control. That's another thing that is not well documented in the guide yet and is something that we have to go through and make a little bit more explicit. So there's a number of places where we have the opportunity to collaborate here with the community and get that discussion rolling. The customer responsibility matrix, like I was saying earlier, is of interest to open shift consumers. And there's a couple of different sort of use cases for this guide. One would be where you are hosting your own open shift environment. So you host you host it, you run it and then you consume the services. So in that case, the group going through that any process would be responsible for both the landlord and the tenant set of controls. If this is in a in a container as a service sort of context, where where you you're just consuming that service and someone else is managing it, then you'd be responsible for those tenant controls. So that's sort of the assumption that we made with this guide that in most cases it's going to be one group that's hosting it for many other customer organizations within that agency. And that's the bit from the customer responsibility matrix that you'd like to give out and make it easier for your your sort of meta customers there to be able to have a very clear picture of what it is that they need to do in order to become accredited when using when using this guide. And like one example of that then would be the control RA3, which is the risk assessment. You have to do that on a per sort of a per program basis. So this is this actually brings up an interesting frequently asked question, which is does this guide mean that open shift is accredited out of the box? And that's that's a no, you can never pre-accredit software. What we're trying to do with this is lower the barriers to entry to get to that accreditation and we're going to get better at that over time. But it shouldn't be thought of as I hand this guide in and that and that means that we're this product itself comes pre accredited somehow that's just not the way it works. Now, I mentioned before any questions on that much before we move on to the Ansible stuff. There was one question Sean tried, I think, answered it here. Jonathan was asking by inherit this control for click through, just to be clear, you mean that because users already have click through on the workstation used to access to open shift, you don't need to need it in the OCP console. Absolutely correct. Yeah. And then Jonathan's asking, any timeline or version target for official FISMA baseline? No, that's always a good question. Yeah, yeah, that we I'll get to that when we when we get to the end, I've got a couple other facts that we can get through. So with the Ansible stuff, we're trying to automate as much of this as possible and make it repeatable. And this further lowers those barriers to becoming accredited when you do this yourself. This is sort of just a temporary placeholder until we get this to a more permanent location. But on Ansible Galaxy, we have an org that is sort of a roll up of many of our standard roles that we've used to implement these things. Just a quick overview. Ansible is a sort of a Python and YAML based configuration management and automation framework. It's very, very easy to use. You just write these YAML playbooks that describe what it is that you're trying to do, although you could write your own Python based modules if you wanted to. And we'll look a little bit more at what some of these look like. But we've been using these to to make this a little bit easier, a little bit more repeatable and particularly to give to our our users who may not be super familiar with the tool so that they can implement it more quickly. And actually OpenShift itself, its deployment mechanism uses Ansible. So with Ansible itself, roles give you sort of a pluggable way of taking a set of playbooks and all of their associated variables and even libraries that they require and make it easy to plug those into the playbook that you're writing. So we've broken many of these things up into roles like the 853 role, for example, implements many of those controls at like a rel level that you have to get through in order to be compliant with all the controls that you see in this guide. That's just sort of a nice to have and it's non-official. The official way to scan for and we're working on the implementation side there that is with OpenSCAP and the SCAP Security Guide. We publish a lot of that stuff and Sean is very, very plugged into that. And I'm sure we'd be happy to talk in depth about any SCAP stuff for SCAP Security Guide stuff, which might even be an appropriate follow-up briefing for the next time we do this .gov stuff. So the 853 role is there. The link will be in the slides for when we send that out if you'd like to play with it. That's broken up in such a way that it's kind of easy for admins to understand what's going on and then make some changes. So this is an example of some of the default variables that are set in this role. And we deliberately made it sort of admin-centric as opposed to compliant-centric. So as an example, if you look at line 12 there with the shared library path, that's very obvious what it's talking about. It doesn't tie that back to some arcane control that then you've got to dig for to see what that means. So this makes it a little bit easier to achieve that accreditation to implement those controls. So that's part of how we've been doing this. Here's another example. We've broken the different tasks down into control family. So in the axis control one, you can see here an enable SC Linux control and then which play and then which controls there actually tie back to that. One of the nice things about this design is using the tags system. You can specify by CIA, low, moderate, or high what controls you actually want to implement. So at runtime you could say I want confidentiality, high, integrity, high, availability, moderate, and then it would tailor it to only apply those different controls. All of this goes into sort of a larger effort that we've been going through to create a way to make it really easy to reproduce fully disconnected deployments of OpenShift. So what does disconnected mean in this context? When you typically deploy OpenShift on a system that has connectivity to the internet, you've got a lot of resources that are available to you that you might not have in a fully air-gapped environment. You can register your system with the Red Hat content delivery network. You can pull your RPMs down simply by enabling those repos and running the various prerequisite commands and then the deployment ansible playbook. If you have to pull down any additional Docker images that you might not have locally, you can go out and get those from the Red Hat registry or from some other registry. Doing these things when you have no ability to hit the internet makes deployment very, very challenging. So the goal of this effort was to not just come up with a way to implement that reference architecture in the security con off, but also to make it easier to, for one thing, practice doing those disconnected deployments because you actually learn a lot just in going through it once in say like a private VPC like we're doing here in this project. And then you can take all of those deployment artifacts that you pull down into your bastion VPC there, tar those up, bring them across your air gap and have a much easier time successfully deploying that on your disconnected environment. So that's what we're doing there. If we were to describe the compliance guide and none of this is actually official, so but if we were to think of the compliance guide as sort of being at a beta degree of maturity, this OpenShift disconnected effort would still sort of be an alpha. There are a couple issues that we have not quite tracked down yet, just due to time constraint around the deployment, not completing particularly like with the HAProxy load balancer. So we have some opportunity for collaboration and improvement there, but in the long term, I think this is gonna be one of the easier ways to actually achieve those disconnected deployments. Oh, we've got a couple of typical questions that I wanna hit, but before we move on, any questions about the Ansible stuff? Well, Sean is saying that he really, really loves the disconnected install scripts and he's asking any plans to work with OpenShift product management to formally incorporate and add support for disconnected installs? Absolutely, yes. So the goal for all of these, so that segues nicely. So these are the four most common questions that I encounter when talking about this stuff. And is it official? And the answer is not yet. This is something that was born out of the public sector group within Red Hat. Sort of it came from the field with a lot of deployments that we've done. We're trying to sort of get it to a point where other people are gonna be able to understand it and then like we're doing now, we're sort of opening that up more to the community so that we can get it to a usable state and get that incorporated upstream. So our goal would be to get this compliance guide hosted off of the official docs.openshift.com and docs.redhat.com sites. But it's not official yet and there's a lot of work that we need to do to be able to get there. Nor is it complete. Like I was saying earlier, we're missing many different implementations such as the security banner. And we as a community sort of need to decide how we want to approach that. Do we wanna continue with that janky JavaScript window? Probably not. We probably wanna get RFBs open so that it's a parameterized value within the OpenShift tool itself where you can specify I wanna have a banner of this height and color with this content. And one thing to always bear in mind is no matter how official or accurate we can make this guide, it never ever makes OpenShift accredited air quote out of the box. You have to have a sponsor program. You have to have your own system security plan and in your full body of evidence that you put through that A&A process. It is a per program, per effort type thing that simply cannot be generalized at the product level. But what we can do is help you get through that more quickly and help you educate your accreditors so that they're more comfortable getting through that. And we wanted to do this in an open source way because we're a 100% open source company. If like we were saying earlier with the FedRAMP SSP template, it comes pre-populated with headers and footers that say company proprietary trade secret type stuff. And typically that's how this type of data is handled. A company might put some effort into making it easier to get through accreditation. But that then becomes some more secret sauce to entice you to use that product. That's just not how Red Hat rolls. We wanted to do this in a fully open source way. And I think everybody's gonna benefit from that. Any other questions? No, we might unmute Sean and let him talk a little bit too. He's adding some commentary here. You just find Sean in the list of people who go. Sean, if you unmute yourself, you should be able to talk. Oh yeah, I'm here. I don't know what I could add. Jason's doing really great work. On the accredited out of the box thing, one of the things we're trying to do with Red Hat marketing as well as within public sector is create kind of this government ready concept where using REL7 as the example, we ship government paperwork, like the accreditation paperwork. So all of the control mappings Jason's showed that spreadsheet thing, all of the implementation guidance and the idea is to start going through regulated baselines like the STIG, which is for DOD, BISMA, which is largely for civilian and actually ship government ready deployments or government ready reference architectures. And kind of what Jason's done is set us up for success to do that for OpenShift. All right. Jason, do you have any more slides tucked up your sleeve there? No, I do not. But thank you very much for the opportunity to share this. I'm really looking forward to more community involvement here. We've already had a couple folks from some of our agencies provide a little bit here and there. But when we approach this in the open source way, I think it's gonna make this easier for everybody. Yeah. Well, I also liked your suggestion that maybe having a follow-up on OpenScap would be a good thing as well. Plus, once we get this up and out onto the blog site and other people who wanna put comments on it, if you wanna post another one to review the issues list and have a conversation about that as part of the OpenShift Commons DOV SIG, I'd be happy to do that to help drive through this in that shape and get some community feedback on it. So if anyone's on this call that it has further things that they'd like to see in this guide, please do pull an issue or contribute something, make a pull request and create the content and we'll try and get that out there into this guide as well and give you a place to have conversations about it here in the GOV SIG. I'm looking to see if there's any more questions if you enter them into the chat. We hopefully Jonathan's saying that hopefully he can contribute to it in the future. We hope you all will too. So Jason, it doesn't look like there's any more questions. Sean, thank you very much for doing this session. It's hopefully this work will get incorporated into the product management workflow and get out there in a relatively short time. So thanks again, Jason and I look forward to having you guys on again to do OpenScap. Thanks Diane. Take care guys.