Unable to render Jira issues macro, execution error.

Requirement Summary

 

At present (Knox 0.4), all the clusters fronted by a Knox instance have to be either secure (secured with Keberos) or non secure. In other words, you can not have a mix of secure and non secure clusters.

This Jira proposes adding support for mix of secure and non secure clusters by a single Knox instance

 

Analysis of existing implementation

At present,  global Knox config file,  gateway-site.xml  references to krb5.conf and JAAS login config file krb5JAASLogin.conf files.

In addition there is a global boolean flag in gateway-site.xml, gateway.hadoop.kerberos.secured.

This flag indicates whether hadoop cluster is secured with Kerberos.

As this flag is defined at global level,  we do not have the choice to have some of the clusters fronted by Knox secured and other clusters secured by the same Knox instance not secured by Kerberos.


Proposed Design

Design Summary

 

We would add a boolean flag, hadoop.kerberos.secured,  in topology file.

By doing this,  we can configure single instance of Knox to front a mix of secure and non secure clusters.

Please note that all secure clusters would point to same KDC and share same krb5.conf and krb5JAASLoging.conf defined  globally in gateway-site.xml.

 

Description

 

The boolean flag, hadoop.kerberos.secured, in topology file would be consulted by multiple providers.

So, it would be appropriate that this parameter is added at topology level than within a provider.

To do that, it is proposed that we add a new XML element  <topology-params> as child element of root element <topology>.

<topology-params> could have any number of <param> elements.

 

For example, a topology file would look like the following:

<topology>

    <topology-params>
        <param>
            <name>hadoop.kerberos.secured</name>
            <value>true</value>
        </param>
     </topology-params>

   <gateway>

     ...

    </gateway>

...

</topology>

Alternative solution based on use of identity assertion provider for kerberos (could also consider trusted-proxy as the name):

<topology>

   <gateway>

       ....

       <provider>
           <role>identity-assertion</role>
           <name>Kerberos</name>
           <enabled>true</enabled>
       </provider>

    </gateway>

    <service>

    ....

</topology>

The support for topology wide parameters could be seen as independent feature without any dependency on support for mix of secure and non secure cluster.

Rather support for secure and non secure clusters depends on this feature.

Any feature that requires a need for topology wide parameters could use the feature.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • No labels