inline... On Wed, May 18, 2016 at 8:48 AM, Ellis, Tom (Financial Markets IT) < [email protected]> wrote:
> Hi, > > > > I’m trying to collate my options and gather some examples on how to have > Knox set up in front of a Custom REST API in a Kerberised Cluster. As an > example, the custom rest api would be running queries against an HBase > server. We’d like the user outside the cluster that is authenticated with > Knox (users are in Active Directory so need this set up too) to be used > when querying HBase (HBase authorised by Ranger and we have SSSD/User sync > configured). > > > > Am I correct in understanding that Knox by default will add a doAs request > parameter for the authenticated user when configured in a kerberised > cluster that can then be used by the service? > > > > I’m a little uncomfortable with that just being it though, as then > obviously anything inside the cluster with access to the service can > pretend to be anyone. > Rightly so. Without mutual authentication and an explicit trust relationship between a proxy like Knox and a service, this would be very insecure. > > > > What are my options for making this a bit more robust? > > > > From previous reading through the Knox mailing list it seems I can use > something in the hadoop-auth package, would anyone have any further details > or an example of that? > This pattern is extremely common in Hadoop. You can look at what is done in the Hadoop KMS module as a recent-ish example. Note that, as I mentioned above, you need the trusted proxy config aspect as well in order to establish an explicit trust relationship for allowing services to act on behalf of other users. KMS also does this. > Is it possible for Knox to authenticate and obtain a delegation token (so > as to not have to perform SPNEGO again at Custom REST API) and add it to > the request, and then have the custom API validate this token securely? > Delegation tokens are acquired by authenticating to the target service via SPNEGO. If you don't integrate the hadoop-auth module in your custom service than how would Knox do this? There is certainly no support for such a pattern in Knox today. > I’m assuming this then will add the need for HTTPS comms internally in the > cluster to protect the token? > > > If the above were possible then, yes, it would be prudent to only send such a token over HTTPS. As for other options... 1. You could use the Knox WebHBase service 2. You could potentially build your custom service as a Jersey service that is actually hosted inproc to Knox. This is not something that is commonly done and has obvious implications for the stability of the gateway with your own code running inside. May be worth a POC though. See the KnoxSSO [2] service as an example. 1. https://github.com/apache/hadoop/tree/trunk/hadoop-common-project/hadoop-kms 2. https://github.com/apache/knox/tree/master/gateway-service-knoxsso > Cheers, > > > > Tom Ellis > > [email protected] > > > > Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank > plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in > England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. > Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. > SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered > Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales > 2299428. Telephone: 0345 603 1637 > > Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential > Regulation Authority and regulated by the Financial Conduct Authority and > Prudential Regulation Authority. > > Cheltenham & Gloucester plc is authorised and regulated by the Financial > Conduct Authority. > > Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester > Savings is a division of Lloyds Bank plc. > > HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in > Scotland no. SC218813. > > This e-mail (including any attachments) is private and confidential and > may contain privileged material. If you have received this e-mail in error, > please notify the sender and delete it (including any attachments) > immediately. You must not copy, distribute, disclose or use any of the > information in it or any attachments. Telephone calls may be monitored or > recorded. >
