search

seanorama / masterclass

Materials for various Hadoop & Nifi related workshops
49 stars 67 forks source link

Knox SSO redirects contain the EC2 host's private IP (obviously not working in browser) #10

Open lhoss opened 5 years ago

lhoss commented 5 years ago

@abajwa-hw this issue is about your fork (latest master from today), which does not allow to create issues

In short: Unless we missed something in the Setup Doc, we assume this might be a/the bug, that the (SSOCookieProvider) sso.authentication.provider.url setting is using the Knox host's private IP.

We deployed the hortoniabank demo on AWS, trying 2 different strategies:

Both setups worked well.. by following the steps as documented (the latest version, recently updated! ): https://community.hortonworks.com/articles/151939/hdp-securitygovernance-demo-kit.html

  1. For Knox SSO, you will need to create a entry for demo.hortonworks.com (pointing to the Public IP from above) in your local laptop's hosts file.
  2. After 5-10 minutes, open the below URL in your browser to access Ambari’s console: If you selected an AMI that has Knox SSO, use either Firefox or Incognito Chome window to navigate to http://demo.hortonworks.com:8080 where you will be shown the Knox sign-on login page. Enter user:admin password:BadPass#1

Still new to this demo, and also Knox in general, I'm wondering if it's good idea to use the hostname cmd (which indeed returns the private network IP) to set the "knox_sso_url" in: https://github.com/abajwa-hw/masterclass/blob/master/ranger-atlas/HortoniaMunichSetup/10-SSOSetup.sh#L82

hostname=$(hostname -f) knox_sso_url="https://$hostname:8443/gateway/knoxsso/api/v1/websso"

Finally in the Knox UI I found following setting, which AFAIU is used to generate the redirect URLs, but trying to change it to use the public IP did not succeed (when hitting save button, I get redirected to the Knox login, and after login in the config is still the old one. It seems the 'save' request was redirected, and so did not complete)

We really want to understand if we missed something, or the Doc. is incomplete or if this is even expected .. but then you would also need the browser to be able to handle the private (AWS) IP, for ex. by using Socks Proxy tricks etc

abajwa-hw commented 5 years ago

@lhoss thanks for your detailed note. This is the first time we've added Knox SSO feature so am sure there are improvements we can make (esp when deploying on public cloud). Could we discuss over webex? Would you mind emailing me at abajwa@hortonworks.com with some open slots this week? Am based in Pacific timezone

lhoss commented 5 years ago

thx @abajwa-hw for your quick reply (and I will soon contact you by mail, also about other ideas we have, like if it's possible to better separate the demo setup from the pure HDP/HDF installation, which we prefer todo using ansible and the great role https://github.com/hortonworks/ansible-hortonworks !)

About the issue here: After studying some Knox Docs, the proper solution quickly jumped into our eyes: Adding a Hostmap provider as shown in this example, which is exactly our use-case !:

lhoss commented 5 years ago

We started adding a static hostmap provider (we did several trials, adding to multiple topologies including topologies ui, admin) but it still did not work as expected: After entering the user/pass in Knox, it redirects to the UI, p.eg. YARN UI, but quickly again back to Knox (as if the auth. did not fully work) Also with Zeppelin, it still redirected to a private IP URL, until we fixed following (then Zeppelin has the same problem then described just before)

lhoss commented 5 years ago

We got it working, incl. following gateway'ed URLs: https://demo.hortonworks.com:8443/gateway/ui/zeppelin/ https://demo.hortonworks.com:8443/gateway/ui/ambari https://demo.hortonworks.com:8443/gateway/ui/ranger https://demo.hortonworks.com:8443/gateway/ui/atlas https://demo.hortonworks.com:8443/gateway/ui/yarnuiv2 FAILS: https://demo.hortonworks.com:8443/gateway/ui/yarn ( with http 400, not sure why .. but not a big issue)

after having applied following patches: https://github.com/jnowakowski/masterclass/commits/patch-1 In short, in the provider/SSO related configs we used demo.hortonworks.com as hostname (instead of the former private-IP. ps: We also tried the public-IP, which wasn't working, due to endless redirect to KnoxSSO login.. ) Note: This is without using any static hostmap providers, which I'ld have expected to be the clean solution (but could not figure the exact combination where to configure static hostmaps and where to use internal vs public hostnames)