The OpenShift team at Red Hat has put together a GREAT compliance guide for OpenShift. This doc does a great job detailing each control in NIST 800-53. There’s one major compliance issue that this document explicitly leaves to the “Organization” – identity management. As you go through this document you’ll notice that nearly every control that deals with identity management and compliance is the “Organization” responsibility. In fact, in the overview section for the controls when defining the “Organization” the document states:
A control that is satisfied by the hosting organization. This includes enterprise services such as LDAP, the Audit and Logging solution, etc.
So right there we start with stating identity management components are outside of OpenShift’s responsibilities. These are controls that you as the implementer still need to prove compliance with.
What Is Identity Management?
First, lets define identity management. Its the Who, What and Why of access. Who has access? What do they have access to? Why do they have that access? nearly every control dealing with identity that is marked as owned by the “Organization” deals with answering these three questions.
How Does it Apply to Compliance?
The controls break down into two categories:
- Policies – Section AC-1 is basically a paper game defining what are the rules by which someone should have access to OpenShift
- Technology – The rest of the identity management controls deal with making sure that your OpenShift deployment meets the policies defined by your Organization
Lets take AC-7 “Unsuccessful Logon Attempts”. This one is marked for the “Landlord” not the “Organization” but its still important. If someone logs in with the wrong password too many times they need to be locked out. Note that it doesn’t say HOW MANY times is too many times, that needs to be defined by your organization’s policy. OpenShift has no way of enforcing this, so you need to enforce this elsewhere. This is an example of the “Who” of identity management.
AC-2 “Account Management” encompasses the “What” and “Why” of access. Not a single control here is marked as OpenShift’s responsibility so you as the implementer will be responsible for compliance in this section. Lets use Part K as an example
Authorizes access to the information system based on: 1. A valid access authorization;
OK so that extremely simple and well explained control (thanks NIST) says that you have to be authorized for access. So how were you authorized? Was it according to the policies you need to identify to meet the controls in section AC-1? How do you prove that during an audit?
Can You PLEASE Speak In a Language I Understand – TECHNOLOGY!!!
How do these compliance requirements translate in technology? Thats a pretty complicated question but here are some starting points:
OpenShift needs to know who you are (the “Who” of identity management). This is the easiest part, usually. Most organizations implementing OpenShift will have Active Directory (AD). Its also usually pretty easy to connect to AD via LDAP. OpenShift makes this really easy and is covered really well in its documentation so I’m not going to focus on the details here.
So we’re done, right? Well, remember AC-7? If you use LDAP with Active Directory it does NOT lock you out after too many failed authentications. Go ahead, try it. Give as many failed passwords as you like via LDAP. Brute force all day long you won’t get locked out by AD (though maybe by some very agitated sys admins).
OK so we need something else to do this for us to satisfy this control. There are several options. If you use FreeIPA/Red Hat Identity Management for your LDAP store you’re all set. Do you have an identity provider of some kind? Maybe Keycloak? Maybe Ping or OpenAM or …? Maybe even OpenUnison? There are several you can use as OpenShift supports OpenID Connect out of the box which will work well with anything really. It’d be nice if OpenShift supported SAML2 but frankly there are so many ways to bridge that gap it shouldn’t be an issue. Another great reason to go with an OpenID Connect implementation is it opens up more authentication options such as multi factor that is supported by your identity provider.
So as long as you’re careful and very detail oriented chances are your organization either already has a way to support the controls related to authentication or it would be pretty easy to get something in place. How complex this needs to be really depends on your business need or mission. For instance, are only internal users accessing this system or external users too?
By the way, if you got here because you’re looking for help with Kubernetes then everything I just said about authentication does NOT apply. Check out our wiki page on Kubernetes for a discussion of authentication. But don’t go too far, the authorization section mostly applies to Kubernetes too!
Strap in kiddos, this is where we go down the rabbit hole. In order to be compliant you need to first have a policy that details how access is to be granted. This is usually called a “workflow” in identity management terms. It will often look something like this:
That looks easy, right? Get the user’s manager’s approval then get the OpenShift owner’s approval. Well, do you know who the user’s manager is? Its in AD, RIGHT? We’ll come back to that later. For now lets just assume you know that somehow. Now we need the system owner’s approval. Thats whoever owns OpenShift, right? Well, is it? The great thing about OpenShift is that it makes it really easy to let application owners control management of their application WITHOUT relying on the folks who own OpenShift, so really shouldn’t the application owners be the one to do the approval? How do you know for each project who that approver is? Lets just assume you know that for now. Finally, provision the access! How does OpenShift do that exactly?
Where OpenShift provides a very simple interface to LDAP for authentication, it has no idea how to talk to an LDAP directory like AD to authorize users at the time the decision needs to be made. OpenShift stores all of its users and groups and policies inside of EtcD as objects. You have a policy that defines what can be done and then that policy can be bound either to a user or a group of users. The same is true of the cluster too, there are policies and groups that are specific to the cluster and provide global support.
There are three ways you can manage this:
- LDAP Synchronization
- The oc and oadm commands
- The OpenShift API
The first option is the one that is generally talked about when it comes to externalizing authorizations. OpenShift comes with a utility that lets you synchronize an LDAP group into an OpenShift group. This OpenShift group can then be added to a role in a project. So “Provision Access” in the workflow above means:
- Add the user to the group
- The next time the LDAP sync utility runs the user will be added to the group in OpenShift
Now, every time you want to add a new project you need to create groups in your directory for the appropriate groups in OpenShift and setup new instances of the LDAP sync tool. Oh and remember availability is really important. The LDAP sync tool is a command line tool that you run with a cron job of some kind. I suppose you could setup pods that do it but this really doesn’t feel very DevOpsy. And which LDAP server are we talking about anyways? You want to use AD? Did you ask the person who owns AD’s opinion on this? OK so you can’t use your AD because its not on the AD owner’s list of things to care about (can you blame her? if your system was responsible for making sure everyone can login to their workstations wouldn’t you be kind of protective of letting people make changes?) so you’ll stand up your own directory. You don’t have any more budget so lets go with OpenLDAP or 389 or OpenDJ or … you have an LDAP expert on the team, right? How exactly are you adding users to that directory anyways? We’ll come back to that.
Option two is to use the a combination of the oc and oadm commands to add users to groups and groups to policies in projects. Your system admins love nothing more then manually running these commands, right? We could script it but lets be honest these tools are really just using option three.
Finally option three is we call the OpenShift APIs directly. OK, now we’re getting into DevOps right? I’ll just get a token and write some scripts. I can even write a bunch of micro services to do this!
Remember when I asked how you knew who the approvers were? Whats the escalation policy (ie what happens when someone doesn’t act on a request in time)? You know where the groups are, right? Oh, what happens when someone needs to be de-authorized? There’s going to be a policy on that too. Don’t forget you need to be able to track everything including the reasoning and be able to report on it too. How often do they need to be re-authorized for access? There are more regulations to comply with then just NIST 800-53. And to be really DevOps you don’t want to get humans involved every time a new project is deployed, right?
My investors and sales team are all yelling at me that I’ve written a blog post that summarizes 15 years of identity management experience and how to apply it to compliance with OpenShift without telling you why Tremolo Security helps you solve these problems. Before my past brethren at the Audit Firm wing of the Free Masons come after me for leaking all our closely guarded secrets I should probably get to that. The short version is all those micro services we talked about before? You know, the ones that you were going to write (which won’t effect your budget or time lines at all)? We already built it and its ALL OPEN SOURCE!!!!!!
Our integration with OpenShift lets you:
- Define template workflows like the one above that can be applied to all of your projects
- Provide RESTful APIs for requesting access, approving access
- An AngularJS interface to get you started with the APIs quickly
- A simple relational database schema that can be reported on by our own tools or using your organizations existing business intelligence suite
- Provision access DIRECTLY into OpenShift using the APIs, no need for an LDAP directory for authorizations
- If you don’t have an identity provider for authentication, we can do that too
Your customers say “Give me a project”, probably via some kind of web application or lever or something and all you need to do is add some annotations, create the right groups in OpenShift (which is easy to automate) and add them to the correct policies. All of the compliance stuff? We got you covered! (Get it, COVERED! Thats an audit joke)
Now you might be thinking, doesn’t Red Hat have a tool that does this? Not really. You could probably cobble something together with a combination of CloudForms and jBPM but then you’re basically writing your own identity management system. So while neither Unison (commercial) or OpenUnison (open source) are Red Hat products the good news is we’re already Red Hat partners and part of the OpenShift and Red Hat eco system! Want proof (this IS a blog on compliance after all)? Here’s the link to our OpenShift Primed entry and our Red Hat certified containers. Finally, here’s the OpenShift galaxy that came from OpenShift’s own twitter handle showing us in galactic North :
If you made it this far, I bet you can’t wait to try this out. There are two ways to get started. If you like having a UI to get started, go ahead and register for a 60 day trial license. You don’t need to talk to ANY sales folks to get started, I PROMISE. If on the other hand you like to start with the open source stuff check out our documentation. Its got step-by-step guides for getting OpenUnison up and running quickly. Also checkout our quickstarts on GitHub.
Finally, once you get compliance taken care of for OpenShift, what about the identity management controls for the apps ON OpenShift? Don’t worry, we got you covered there too! (Thats another compliance joke!)