METRON-1945: Metron MPack support for Knox SSO setup

[merrimanr]

Contributor Comments

This PR is based on #1275 and adds Ambari MPack support for enabling Metron on Knox. This makes the setup process simpler, consisting of only a couple steps.

Changes Included

• Added code to the Ambari METRON_CLIENT component that performs the necessary setup/installation for Metron on Knox
• Added metron.knox.enabled and metron.knox.sso.pubkey properties to Ambari
• Added Metron Knox topology files as templates in Ambari so the correct hosts can be configured automatically
• Added app-config.json files as templates in Ambari so the correct paths can be configured automatically
• Added a check for LDAP, throwing an error message if it is not enabled
• Added logic to populate the Spring active profiles and options on REST startup

Testing

This has been tested in full dev. The setup steps are similar to #1275 but should be substantially simpler with less manual work involved:

1. Add Knox as a Service in Ambari (Admin > Stacks and Versions > Add Service next to Knox)
2. Verify the LDAP check is working. Navigate to Ambari > Metron > Configs > Security and set Knox Enabled to true. Restart the Metron REST component and it should fail with this error:

Enabling Metron with Knox requires LDAP authentication.  Please set `LDAP Enabled` to true in the Metron Security tab.

Change Knox Enabled back to false and save.

3. Follow the instructions here to enable the Knox LDAP in full dev. You should be able to authentication with REST using guest/guest-password after this is done.
4. A Metron Client instance is required on all Knox Gateway hosts. Navigate to Ambari > Hosts > node1 and select the Install clients option in the dropdown next to the clients, at the bottom of the Components section. This should install the Metron Client.
5. Get the Knox public key with the following command on full dev:

openssl s_client -connect node1:8443 < /dev/null | openssl x509 | grep -v 'CERTIFICATE' | paste -sd "" -

Copy the output of that command and paste to the Ambari setting at Metron > Configs > Security > Knox SSO Public Key. Change the Knox Enabled setting right above that to true and save.

6. You should be prompted to restart Metron Client, Metron REST, Metron Alerts UI and Metron Management UI. Follow the prompt and restart these components.

After REST comes back up Metron should be enabled for Knox. You should be able to follow the instructions in the #1275 description for verifying that SSO is working for all services.

Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.

In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:

For all changes:

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
• Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
• Has your PR been rebased against the latest commit within the target branch (typically master)?

For code changes:

• Have you included steps to reproduce the behavior or problem that is being changed or addressed?

• Have you included steps or a guide to how the change may be verified and tested manually?

• Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:

  mvn -q clean integration-test install && dev-utilities/build-utils/verify_licenses.sh 
  

• Have you written or updated unit tests and or integration tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via site-book/target/site/index.html:

  cd site-book
  mvn site
  

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

[anandsubbu]

Great work, @merrimanr ! Besides a minor hiccup, I was able to spin up and get this working on a multi node cluster fine. Some comments inline.

[anandsubbu]

This step fails on a multi node install since $METRON_HOME will not be present on a non-Metron node. We need to add a step to create the directory $METRON_HOME/config/zookeeper before updating the metron_knox_installed flag file.

Attached is the from Ambari when restarting Metron Client on a non-Metron node.
restart-metron-client.log

[anandsubbu]

I checked this behavior on a kerberized environment. Here is the folder structure on a node without Metron services:

[root@metron-1 ~]# cd /usr/metron/0.7.0/
[root@metron-1 0.7.0]# ll
total 4
-rwxr-xr-x. 1 metron metron 688 Dec 21 10:18 client_jaas.conf

Restarting Metron Client service is still failing with this error:

    raise Fail("Applying %s failed, parent directory %s doesn't exist" % (self.resource, dirname))
resource_management.core.exceptions.Fail: Applying File['/usr/metron/0.7.0/config/zookeeper/../metron_knox_installed'] failed, parent directory /usr/metron/0.7.0/config/zookeeper/.. doesn't exist

The config/zookeeper within $METRON_HOME needs to be created before we write the flag file.

[merrimanr]

Thanks @anandsubbu. The latest commit creates this directory if it doesn't already exist.

[anandsubbu]

When I click in Ambari -> Metron service -> Quick Links -> any of the links, it does not get redirected to the Knox gateway. Does this need to be fixed as well?

[merrimanr]

I also pushed a commit out that exposes the Knox SSO Token TTL as an Ambari setting and changes the default to 5 minutes. The default was 30 seconds and I can't imagine anyone would ever leave it set to that. Is 5 minutes still too short or should it be expected that an administrator will need to change it? Any thoughts on what this should be?

I tested this again in full dev and the TTL setting works as expected.

[merrimanr]

@anandsubbu as far as I know Quick Links must be changed manually. There is a section in the README explaining this.

I believe all feedback has been addressed. Let me know if I missed something.

[mmiklavc]

I also pushed a commit out that exposes the Knox SSO Token TTL as an Ambari setting and changes the default to 5 minutes. The default was 30 seconds and I can't imagine anyone would ever leave it set to that. Is 5 minutes still too short or should it be expected that an administrator will need to change it? Any thoughts on what this should be?

I tested this again in full dev and the TTL setting works as expected.

I'm fine with 5 min, and I'd probably also take a quick look at a couple other hadoop services to see what they're setting it to.

[merrimanr]

The only example I can find is the SSO topology that ships with Knox and it's set to 30 seconds.

[mmiklavc]

Just a clarification:

Verify the LDAP check is working. Navigate to Ambari > Metron > Configs > Security and set Knox Enabled to true. Restart the Metron REST component and it should fail with this error:
Enabling Metron with Knox requires LDAP authentication. Please set Knox Enabled to true in the Metron Security tab.

Check for Please set "LDAP Enabled" to true, not Knox Enabled (we enabled Knox already, still need to enable LDAP). The Ambari REST api restart log output shows as expected.

[merrimanr]

You're correct. Fortunately it's only the testing instructions that were incorrect. Fixed.

[mmiklavc]

@merrimanr Great job on a big submission. I ran this up in full dev and everything seems to be working properly, including timeouts and logouts. I also see @anandsubbu has put this through its paces in a multi-node deployment, which is great. +1 from me pending the latest Travis build succeeding. You also have a +1 from on #1275, so this feature should be ready to roll.

[anandsubbu]

+1
Looks good @merrimanr !