-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to run osprey using dex along with other login applications #20
Comments
Hi @rosskusler. I don't think you will be able to run two instances of Dex running for the same cluster for the reasons you gave. Only one of them can be the authority for the apiserver. Osprey currently does not handle Dex with multiple connectors or, like in your case it doesn't handle different templates based on client ids. Would the backend be the same for both clients? Or would you have different connectors for each client? If the former, then if you wish you could submit a proposal as to how to handle this scenario. If you have different connectors then Osprey would require that change as well. |
The backend would be the same for both the dashboard and the kubectl, a corporate LDAP server. One possibility could be to allow osprey to handle cases where dex returns web/ content containing html rather than json. It looks like all of the data included in the json templates is also included in the stock html templates, it would just take some parsing to get to. Along with allowing the dashboard and osprey to run alongside each other using the same authentication system (which I'd assume others would find valuable too) this would simplify the deployment of osprey by eliminating the need to have any custom templates mounted within dex. However it would be somewhat fragile and could break when dex changes their html templates. |
We based the Json templates on the html ones, so they should be a complete match. We didn't want to follow the html parsing route, because I think dex also has some connectors that allow a custom page to be served (e.g. Login), and thus a generic template would not work for those pages. We do not have any other use for dex other than our osprey client, so the custom templates with Json was the more straightforward way to go. We probably need a way to describe the expected fields required from the html responses, so that they can be processed correctly. |
Removing the need of mounting custom templates might be a good idea, as we currently have someone with an issue related to mounting those templates #12 |
@rosskusler i have a branch with changes that will enable the use of the dex templates for osprey. |
I expect that osprey will have to be a bit more dynamic, as different connectors may also return different responses, for example the saml connector, which does not use the dex templates |
@totahuanocotl I will give it a try.. thank you very much! |
Any chance you are going to upload an image of the container for that branch? I am/was trying to make a image, but ran into some problems. |
sorry @markdanko I just saw your comment. Are you still interested in that image? |
Thanks, I managed to get the image created and am all set now.
…On Fri, Feb 15, 2019, 7:43 AM Isaac Martinez Aceves < ***@***.***> wrote:
sorry @markdanko <https://github.com/markdanko> I just saw your comment.
Are you still interested in that image?
If you want I can help sort out the issues you are having with the local
build.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AI54bC7HnAV8lf9A_pGkdfGsRhlYOoRVks5vNquAgaJpZM4WPrIE>
.
|
I have osprey working successfully in my lab using an instance of dex with the modified web/templates that replacing the html with json. I really like the fact that osprey can collect the username/password from the command line rather than having to launch a browser.
In our production clusters we are already using dex along with auth2_proxy to provide authentication for our dashboard. In this case we need to use the stock dex web/templates because they provide the HTML for the login page.
Is it possible to support both the dashboard and osprey at the same time using a single instance of dex? I haven't come across any way to serve different web templates based on the application/clientId being used, but this would be ideal. Alternatively, is it actually possible to use two different instances of dex, one dedicated to osprey and the other dedicated to the dashboard? I had considered this approach but then I'd have two different certificate issuers and the kubernetes API only allows us to specify a single OIDC issuer url. Even if the two instances user the same certificates, they would have different URLs for discovery, generating and refreshing tokens.
I would really appreciate anyone's feedback on this.. thank you!
The text was updated successfully, but these errors were encountered: