You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by "Jim R. Wilson" <wi...@gmail.com> on 2008/05/13 17:13:27 UTC
[hbase-user] Secure, authenticated remote hbase api access
Hi all,
For our project we're using Hbase's Thrift service for communication
between hbase and our web application (PHP) and maintenance scripts
(Python). I've got an hbase cluster setup in EC2, but I'm drawing a
blank on how to do the communication in a secure, authenticated way.
Does anyone have any ideas? Is there already a plugin or service I
can just lay on top of my existing hbase setup?
Thanks in advance for any help.
-- Jim R. Wilson (jimbojw)
Re: [hbase-user] Secure, authenticated remote hbase api access
Posted by "Jim R. Wilson" <wi...@gmail.com>.
> The simplest thing I can think of would be to use firewall rules to
> allow traffic only from your other systems - that is, wherever your PHP and
> Python scripts might be running.
Yeah, that's what I suspected. It's probably easiest to just setup
some IP-restricted firewall rules and call it a day. I'm not sure yet
whether that's sufficient compared to ssh proxy tunneling, but it's
certainly simpler.
I'll probably just do the IP restriction for now. The primary problem
I have with ssh tunneling is error handling - detecting when a session
has died and restarting it, keeping sessions open, that sort of thing.
-- Jim
On Tue, May 13, 2008 at 10:22 AM, Bryan Duxbury <br...@rapleaf.com> wrote:
> I know that there was talk on the Thrift mailing list of a SSL wrapper for
> the socket transport. If that exists, and it's in Java, it would be an easy
> addition and give you the secure side of things.
>
> As far as authentication: as you're probably aware, at this point, we don't
> really have any access control in HBase at all. So, for the moment, if you
> need some sort of authentication, you're going to have to do something above
> HBase. The simplest thing I can think of would be to use firewall rules to
> allow traffic only from your other systems - that is, wherever your PHP and
> Python scripts might be running. It's not a perfect solution, but I think
> it's the best you can get quickly.
>
> -Bryan
>
>
>
> On May 13, 2008, at 8:13 AM, Jim R. Wilson wrote:
>
>
> > Hi all,
> >
> > For our project we're using Hbase's Thrift service for communication
> > between hbase and our web application (PHP) and maintenance scripts
> > (Python). I've got an hbase cluster setup in EC2, but I'm drawing a
> > blank on how to do the communication in a secure, authenticated way.
> >
> > Does anyone have any ideas? Is there already a plugin or service I
> > can just lay on top of my existing hbase setup?
> >
> > Thanks in advance for any help.
> >
> > -- Jim R. Wilson (jimbojw)
> >
>
>
Re: [hbase-user] Secure, authenticated remote hbase api access
Posted by Bryan Duxbury <br...@rapleaf.com>.
I know that there was talk on the Thrift mailing list of a SSL
wrapper for the socket transport. If that exists, and it's in Java,
it would be an easy addition and give you the secure side of things.
As far as authentication: as you're probably aware, at this point, we
don't really have any access control in HBase at all. So, for the
moment, if you need some sort of authentication, you're going to have
to do something above HBase. The simplest thing I can think of would
be to use firewall rules to allow traffic only from your other
systems - that is, wherever your PHP and Python scripts might be
running. It's not a perfect solution, but I think it's the best you
can get quickly.
-Bryan
On May 13, 2008, at 8:13 AM, Jim R. Wilson wrote:
> Hi all,
>
> For our project we're using Hbase's Thrift service for communication
> between hbase and our web application (PHP) and maintenance scripts
> (Python). I've got an hbase cluster setup in EC2, but I'm drawing a
> blank on how to do the communication in a secure, authenticated way.
>
> Does anyone have any ideas? Is there already a plugin or service I
> can just lay on top of my existing hbase setup?
>
> Thanks in advance for any help.
>
> -- Jim R. Wilson (jimbojw)