You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@knox.apache.org by "Ellis, Tom (Financial Markets IT)" <To...@LloydsBanking.com> on 2016/05/18 12:48:04 UTC

Knox in front of Custom REST API in Kerberised Cluster

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.

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? 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? I'm assuming this then will add the need for HTTPS comms internally in the cluster to protect the token?

Cheers,

Tom Ellis
tellisnz@gmail.com



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.

RE: Knox in front of Custom REST API in Kerberised Cluster

Posted by "Ellis, Tom (Financial Markets IT)" <To...@LloydsBanking.com>.
Thanks a lot Larry!

Looks like hadoop-auth is what I’m after, will build a PoC and see how I go.

Cheers again!

Tom Ellis
tellisnz@gmail.com

From: larry mccay [mailto:lmccay@apache.org]
Sent: 18 May 2016 14:08
To: user@knox.apache.org
Subject: Re: Knox in front of Custom REST API in Kerberised Cluster

-- This email has reached the Bank via an external source --

inline...

On Wed, May 18, 2016 at 8:48 AM, Ellis, Tom (Financial Markets IT) <To...@lloydsbanking.com>> 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
tellisnz@gmail.com<ma...@gmail.com>



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.



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.

Re: Knox in front of Custom REST API in Kerberised Cluster

Posted by larry mccay <lm...@apache.org>.
inline...

On Wed, May 18, 2016 at 8:48 AM, Ellis, Tom (Financial Markets IT) <
Tom.Ellis@lloydsbanking.com> 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
>
> tellisnz@gmail.com
>
>
>
> 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.
>