Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Open
lhoss opened this issue Sep 25, 2018 · 4 comments
Open

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

lhoss opened this issue Sep 25, 2018 · 4 comments

Comments

@lhoss
Copy link

lhoss commented Sep 25, 2018

@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:

  • "Option 1" (today) using 'setup.sh' on an official AWS centos-7.5 ami
  • "Option 2" (yesterday) using the "HDP 3.0 without NiFi or Knox SSO" AMI

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
Copy link
Collaborator

@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 [email protected] with some open slots this week? Am based in Pacific timezone

@lhoss
Copy link
Author

lhoss commented Sep 26, 2018

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
Copy link
Author

lhoss commented Sep 26, 2018

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)

  • Zeppelin config fix (done in Ambari)
    Section: Advanced "Zeppelin-shiro-ini " following param needs to use the public-IP in setting:
knoxJwtRealm.providerUrl = https://ec2-xxx-xxx-xxx-xxx.us-west-1.compute.amazonaws.com:8443/gateway/knoxsso/api/v1/websso

jnowakowski added a commit to jnowakowski/masterclass that referenced this issue Sep 26, 2018
@jnowakowski
curl http://169.254.169.254/latest/meta-data/public-hostname
f17d6e2 
seanorama#10 (comment)
@lhoss
Copy link
Author

lhoss commented Sep 27, 2018 •
edited
Loading

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lhoss @abajwa-hw