Bug 1411729
| Summary: | Conditional access to OpenShift based on its origin | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Jaspreet Kaur <jkaur> |
| Component: | RFE | Assignee: | Mo <mkhan> |
| Status: | CLOSED CANTFIX | QA Contact: | Xiaoli Tian <xtian> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.3.1 | CC: | aos-bugs, jliggitt, jokerman, mkhan, mmccomas, simon.gunzenreiner, ssorce |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-10-26 15:18:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jaspreet Kaur
2017-01-10 11:52:48 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 [1] PR (and some more support code) is implemented. [1] https://github.com/openshift/origin/pull/15158 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. 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. OAuth is a bearer token system, there is no way to bind the token to a device. 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 ... 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. Thanks, I see that even if it might work in our case, it would be probably impossible to generalize ... After additional consideration we determined we cannot implement this RFE, so closing. |