Bug 1000595 - OpenShift Security guide
Summary: OpenShift Security guide
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 1.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Julie
QA Contact: Bilhar
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-23 19:28 UTC by Eric Rich
Modified: 2019-03-22 07:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-10 01:10:36 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Eric Rich 2013-08-23 19:28:30 UTC
Document URL: 

We'd like to see an in-depth technical explanation of OSE's security model/architecture that includes diagrams. For example, how and why multi-tenancy is secure within the OpenShift model. How do Virtual IPs on nodes not interfere with the greater enterprise... Why using rhc port-forward is secure... 

In addition to that we'd like to see a security best practices covered. The best practices could cover everything from OSE deployment and configuration to application coding in the openshift environment. For instance, if an application uses a certain OSE env var make sure you do xyz and don't do abc.

Support has provided the following as a start to this: 

Eash node has a publicly rotatable IP that is found via DNS lookups (created when a gear is created). 

Example:
     test-mynamespace.example.com => 11.12.13.1

When a request is made to port 80 (the http port) for this DNS lookup you get routed to the node (and peroxided to your gear/application). The reason that you get peroxided is because each application (cartridges) resides on its own (non-rotatable [out side of the node]) IP

Example: 

     A JBoss application will bind to 127.0.250.1 on port 8080. 

With that said, it is easy to see that in order to get to your gear you must follow this (example below) route. 

     test-mynamespace.example.com (11.12.13.1:80) => 127.0.250.1:8080

The security that is offered by this is that in order to get to any application or cartridge on the open shift node you must do one of two things. You must enter through a public port on the node (80, 443, 22, or the websockets port). This narrows the vector of attack down greatly. The other benefit is that each application is locked down to its gear space with seliux (and because of the port restrictions to the local IP / port) these selinux policies can ensure that the multi-tenants are not effected if a gear is compromised. 

       Node------------------|  IP: 11.12.13.1
       |[-Proxy--(80)-(443)-]|
       |Gear----------------||
       ||Cartridge----------||
       |||Application--IP--|||  IP:127.0.250.1
       |||-[8080]--[other]-|||
       ||-------------------||
       -----------------------

As for port-forwarding, it is just as secure as an ssh port forward. In the diagram above you can see that your Application might bind to other ports but because the the Node proxy does not forward to these ports they are not accessible, unless the rhc port-forward command is run and an ssh tunnel is established between your local system and your gear. 

[0] is some of the RHEL documentation that describes how this is done, however rhc simply makes REST calls to the broker to set up the proper port forwards in this manner with your local system. All of the communication is secured with SSH and the tunnel that it creates. 


[0] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-ssh-beyondshell-tcpip.html

Comment 2 Eric Rich 2013-08-23 20:20:23 UTC
We'd also like to see a more in-depth technical explanation of how selinux (and any extensions to it) and cgroups do their part to protect and enable a multi-tenant environment in the security guide.

Comment 4 Phil Festoso 2013-12-16 16:48:29 UTC
Customer is looking for a document that is as detailed and thorough as the EAP5 Security Guide. I don't have much more than that at this time. I know they are wanting guidance from best practices perspective. I would like to re-open the ticket and start a dialogue with the customer about what the OSE Security Guide should contain.


Note You need to log in before you can comment on or make changes to this bug.