|Summary:||Conditional access to OpenShift based on its origin|
|Product:||OpenShift Container Platform||Reporter:||Jaspreet Kaur <jkaur>|
|Status:||CLOSED CANTFIX||QA Contact:||Xiaoli Tian <xtian>|
|Version:||3.3.1||CC:||aos-bugs, jliggitt, jokerman, mkhan, mmccomas, simon.gunzenreiner, ssorce|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-10-26 15:18:29 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Jaspreet Kaur 2017-01-10 11:52:48 UTC
1. Proposed title of this feature request Conditional access to OpenShift based on its origin of request coming to Openshift API 3. What is the nature and description of the request? we would dynamically provision access rights to OpenShift when a user logs in and an OAuth token is issued. Depending on the users origin, access right would be provisioned conditionally. Also, a mechanism would need to make sure that as long as a user is logged in with a specific token, that token is associated with the users "origin" (so that he/she cannot switch from internal to external access with the same token). 4. Why does the customer need this? (List the business requirements here) Because we use one OpenShift instance for multiple tenants, we have the requirements to treat access to the OpenShift API "conditionally". If a user comes from the internet, he might have access to only a subset of projects. If he accesses the API from trusted networks or devices, he shall have access to all projects. The motivation is to prevent data leakage for some projects (but it should be our tenant's choice for which projects this rule should apply).
Comment 4 Simo Sorce 2017-10-02 12:27:13 UTC
I think the solution for this is to use a frontend authentication service like keycloak, and let it add proper groups to the user identity based on whatever rules are established there for access. This will allow to access some role automatically once this  PR (and some more support code) is implemented.  https://github.com/openshift/origin/pull/15158
Comment 5 Simo Sorce 2017-10-02 12:28:28 UTC
Just to be clear, there is no plan to implement complex logic that looks outwards from our database to determine access. An external IdP will be required to do what is requested by the customer. The details of how the customer filters access will be dealt with in the IdP.
Comment 6 Simon Gunzenreiner 2017-10-02 13:17:28 UTC
An IdP cannot solve this requirement though. An IdP is only consulted at authentication time; but the problem appears later, after OpenShift has issued a OAuth token to the user: It must not be possible for that user to copy that token to another device, and access OpenShift from there.
Comment 7 Simo Sorce 2017-10-02 18:16:23 UTC
OAuth is a bearer token system, there is no way to bind the token to a device.
Comment 8 Simon Gunzenreiner 2017-10-02 18:41:07 UTC
Well, we are not asking for it to be resolved through OAuth alone; just one way to "bind" to token to a device is to store the users IP (e.g. in Etcd), at the time when the token is issued, and check, on subsequent calls, that the user still has that IP. Most certainly you could come up with more sophisticated ideas ...
Comment 9 Simo Sorce 2017-10-02 18:46:54 UTC
That wouldn't work as tokens are transmitted and sometimes there are proxies or other hand offs that would not allow to check IP addresses. Even the initial auth itself may not be able to easily determine a client IP address, depending on network configuration. Embedding IP addresses in tickets has been done before, in kerberos, and had to be subsequently abandoned as it created a lot more problems than it solved. I am not saying there is no way at all to come up with some way to try to restrict some of this, I am just setting up expectations, we do not see a near term solution along the lines you are requesting. It may be easier to monitor and take remedial action (like disabling accounts) by using an external system that correlates logs.
Comment 10 Simon Gunzenreiner 2017-10-02 18:51:28 UTC
Thanks, I see that even if it might work in our case, it would be probably impossible to generalize ...
Comment 11 Simo Sorce 2017-10-26 15:18:29 UTC
After additional consideration we determined we cannot implement this RFE, so closing.