Bug 1000595

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