Cassandra security

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Cassandra security

Mark McBride
I'm looking at the potential of embedding Cassandra in one of our
products.  This ships as one or more virtual appliances that runs at a
customer's site, and security is always an issue.  This looks like
mostly a Thrift issue... but I was wondering if anybody on this list
had any thoughts about how you would go about securing Cassandra.  The
best idea I have so far is to try to get THttpClient working (doc
there is very sparse), have Cassandra listen only listen on 127.0.0.1
and have Apache + mod_proxy handle security.  If anybody thinks this
is a dumb way to do it I'm more than willing to listen to alternatives

   ---Mark
Reply | Threaded
Open this post in threaded view
|

Re: Cassandra security

Jonathan Ellis-3
if your product is jvm based, just use the internal api and don't
stzrt the thrift listeners at all.

On 8/21/09, Mark McBride <[hidden email]> wrote:

> I'm looking at the potential of embedding Cassandra in one of our
> products.  This ships as one or more virtual appliances that runs at a
> customer's site, and security is always an issue.  This looks like
> mostly a Thrift issue... but I was wondering if anybody on this list
> had any thoughts about how you would go about securing Cassandra.  The
> best idea I have so far is to try to get THttpClient working (doc
> there is very sparse), have Cassandra listen only listen on 127.0.0.1
> and have Apache + mod_proxy handle security.  If anybody thinks this
> is a dumb way to do it I'm more than willing to listen to alternatives
>
>    ---Mark
>
Reply | Threaded
Open this post in threaded view
|

Re: Cassandra security

Mark McBride
There's still the question of inter-node communication though.  One of
the attractive things to us is the ability to power on another virtual
appliance and have it auto-discover the other Cassandra nodes.  Is
this just something outside the scope of the current design?

   ---Mark

On Fri, Aug 21, 2009 at 10:30 PM, Jonathan Ellis<[hidden email]> wrote:

> if your product is jvm based, just use the internal api and don't
> stzrt the thrift listeners at all.
>
> On 8/21/09, Mark McBride <[hidden email]> wrote:
>> I'm looking at the potential of embedding Cassandra in one of our
>> products.  This ships as one or more virtual appliances that runs at a
>> customer's site, and security is always an issue.  This looks like
>> mostly a Thrift issue... but I was wondering if anybody on this list
>> had any thoughts about how you would go about securing Cassandra.  The
>> best idea I have so far is to try to get THttpClient working (doc
>> there is very sparse), have Cassandra listen only listen on 127.0.0.1
>> and have Apache + mod_proxy handle security.  If anybody thinks this
>> is a dumb way to do it I'm more than willing to listen to alternatives
>>
>>    ---Mark
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Cassandra security

Chris Goffinet-2
Thrift is just a cross-platform interface. Using the internal api does  
not mitigate having Cassandra find other nodes.

-Chris

On Aug 21, 2009, at 10:39 PM, Mark McBride wrote:

> There's still the question of inter-node communication though.  One of
> the attractive things to us is the ability to power on another virtual
> appliance and have it auto-discover the other Cassandra nodes.  Is
> this just something outside the scope of the current design?
>
>   ---Mark
>
> On Fri, Aug 21, 2009 at 10:30 PM, Jonathan Ellis<[hidden email]>  
> wrote:
>> if your product is jvm based, just use the internal api and don't
>> stzrt the thrift listeners at all.
>>
>> On 8/21/09, Mark McBride <[hidden email]> wrote:
>>> I'm looking at the potential of embedding Cassandra in one of our
>>> products.  This ships as one or more virtual appliances that runs  
>>> at a
>>> customer's site, and security is always an issue.  This looks like
>>> mostly a Thrift issue... but I was wondering if anybody on this list
>>> had any thoughts about how you would go about securing Cassandra.  
>>> The
>>> best idea I have so far is to try to get THttpClient working (doc
>>> there is very sparse), have Cassandra listen only listen on  
>>> 127.0.0.1
>>> and have Apache + mod_proxy handle security.  If anybody thinks this
>>> is a dumb way to do it I'm more than willing to listen to  
>>> alternatives
>>>
>>>    ---Mark
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Cassandra security

Mark McBride
I understand that part.  But how do you prevent people starting a
rogue node and adding it to the system?  As I understand it now,
anybody can bring up a node, point it at one of the seeds and have it
take part in the cluster.  Am I mistaken there?

    ---Mark

On Fri, Aug 21, 2009 at 10:42 PM, Chris Goffinet<[hidden email]> wrote:

> Thrift is just a cross-platform interface. Using the internal api does not
> mitigate having Cassandra find other nodes.
>
> -Chris
>
> On Aug 21, 2009, at 10:39 PM, Mark McBride wrote:
>
>> There's still the question of inter-node communication though.  One of
>> the attractive things to us is the ability to power on another virtual
>> appliance and have it auto-discover the other Cassandra nodes.  Is
>> this just something outside the scope of the current design?
>>
>>  ---Mark
>>
>> On Fri, Aug 21, 2009 at 10:30 PM, Jonathan Ellis<[hidden email]> wrote:
>>>
>>> if your product is jvm based, just use the internal api and don't
>>> stzrt the thrift listeners at all.
>>>
>>> On 8/21/09, Mark McBride <[hidden email]> wrote:
>>>>
>>>> I'm looking at the potential of embedding Cassandra in one of our
>>>> products.  This ships as one or more virtual appliances that runs at a
>>>> customer's site, and security is always an issue.  This looks like
>>>> mostly a Thrift issue... but I was wondering if anybody on this list
>>>> had any thoughts about how you would go about securing Cassandra.  The
>>>> best idea I have so far is to try to get THttpClient working (doc
>>>> there is very sparse), have Cassandra listen only listen on 127.0.0.1
>>>> and have Apache + mod_proxy handle security.  If anybody thinks this
>>>> is a dumb way to do it I'm more than willing to listen to alternatives
>>>>
>>>>   ---Mark
>>>>
>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Cassandra security

Chris Goffinet-2
Sounds like your asking if Cassandra has support for a software ACL.  
No, Cassandra does not have that. I personally think that should be at  
the hardware level anyway, why waste the cycles. Secure your network  
firewalls internally to isolate your appliance. If anything, you could  
ship a software based firewall in your appliance (something that uses  
iptables -- its what we had at Yahoo).


On Aug 21, 2009, at 10:48 PM, Mark McBride wrote:

> I understand that part.  But how do you prevent people starting a
> rogue node and adding it to the system?  As I understand it now,
> anybody can bring up a node, point it at one of the seeds and have it
> take part in the cluster.  Am I mistaken there?
>
>    ---Mark
>
> On Fri, Aug 21, 2009 at 10:42 PM, Chris Goffinet<[hidden email]>  
> wrote:
>> Thrift is just a cross-platform interface. Using the internal api  
>> does not
>> mitigate having Cassandra find other nodes.
>>
>> -Chris
>>
>> On Aug 21, 2009, at 10:39 PM, Mark McBride wrote:
>>
>>> There's still the question of inter-node communication though.  
>>> One of
>>> the attractive things to us is the ability to power on another  
>>> virtual
>>> appliance and have it auto-discover the other Cassandra nodes.  Is
>>> this just something outside the scope of the current design?
>>>
>>>  ---Mark
>>>
>>> On Fri, Aug 21, 2009 at 10:30 PM, Jonathan  
>>> Ellis<[hidden email]> wrote:
>>>>
>>>> if your product is jvm based, just use the internal api and don't
>>>> stzrt the thrift listeners at all.
>>>>
>>>> On 8/21/09, Mark McBride <[hidden email]> wrote:
>>>>>
>>>>> I'm looking at the potential of embedding Cassandra in one of our
>>>>> products.  This ships as one or more virtual appliances that  
>>>>> runs at a
>>>>> customer's site, and security is always an issue.  This looks like
>>>>> mostly a Thrift issue... but I was wondering if anybody on this  
>>>>> list
>>>>> had any thoughts about how you would go about securing  
>>>>> Cassandra.  The
>>>>> best idea I have so far is to try to get THttpClient working (doc
>>>>> there is very sparse), have Cassandra listen only listen on  
>>>>> 127.0.0.1
>>>>> and have Apache + mod_proxy handle security.  If anybody thinks  
>>>>> this
>>>>> is a dumb way to do it I'm more than willing to listen to  
>>>>> alternatives
>>>>>
>>>>>   ---Mark
>>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Cassandra security

Mark McBride
That's not a bad idea.  Doesn't end up being very fine grained, but
should be sufficient.

   ---Mark

On Fri, Aug 21, 2009 at 10:53 PM, Chris Goffinet<[hidden email]> wrote:

> Sounds like your asking if Cassandra has support for a software ACL.  No,
> Cassandra does not have that. I personally think that should be at the
> hardware level anyway, why waste the cycles. Secure your network firewalls
> internally to isolate your appliance. If anything, you could ship a software
> based firewall in your appliance (something that uses iptables -- its what
> we had at Yahoo).
>
>
> On Aug 21, 2009, at 10:48 PM, Mark McBride wrote:
>
>> I understand that part.  But how do you prevent people starting a
>> rogue node and adding it to the system?  As I understand it now,
>> anybody can bring up a node, point it at one of the seeds and have it
>> take part in the cluster.  Am I mistaken there?
>>
>>   ---Mark
>>
>> On Fri, Aug 21, 2009 at 10:42 PM, Chris Goffinet<[hidden email]> wrote:
>>>
>>> Thrift is just a cross-platform interface. Using the internal api does
>>> not
>>> mitigate having Cassandra find other nodes.
>>>
>>> -Chris
>>>
>>> On Aug 21, 2009, at 10:39 PM, Mark McBride wrote:
>>>
>>>> There's still the question of inter-node communication though.  One of
>>>> the attractive things to us is the ability to power on another virtual
>>>> appliance and have it auto-discover the other Cassandra nodes.  Is
>>>> this just something outside the scope of the current design?
>>>>
>>>>  ---Mark
>>>>
>>>> On Fri, Aug 21, 2009 at 10:30 PM, Jonathan Ellis<[hidden email]>
>>>> wrote:
>>>>>
>>>>> if your product is jvm based, just use the internal api and don't
>>>>> stzrt the thrift listeners at all.
>>>>>
>>>>> On 8/21/09, Mark McBride <[hidden email]> wrote:
>>>>>>
>>>>>> I'm looking at the potential of embedding Cassandra in one of our
>>>>>> products.  This ships as one or more virtual appliances that runs at a
>>>>>> customer's site, and security is always an issue.  This looks like
>>>>>> mostly a Thrift issue... but I was wondering if anybody on this list
>>>>>> had any thoughts about how you would go about securing Cassandra.  The
>>>>>> best idea I have so far is to try to get THttpClient working (doc
>>>>>> there is very sparse), have Cassandra listen only listen on 127.0.0.1
>>>>>> and have Apache + mod_proxy handle security.  If anybody thinks this
>>>>>> is a dumb way to do it I'm more than willing to listen to alternatives
>>>>>>
>>>>>>  ---Mark
>>>>>>
>>>>>
>>>
>>>
>
>
dpp
Reply | Threaded
Open this post in threaded view
|

Re: Cassandra security

dpp


On Fri, Aug 21, 2009 at 10:56 PM, Mark McBride <[hidden email]> wrote:
That's not a bad idea.  Doesn't end up being very fine grained, but
should be sufficient.

My understanding is that Erlang OTP has a reasonable security layer for inter-machine communications that might address the rogue Cassandra instance issue.
 


  ---Mark

On Fri, Aug 21, 2009 at 10:53 PM, Chris Goffinet<[hidden email]> wrote:
> Sounds like your asking if Cassandra has support for a software ACL.  No,
> Cassandra does not have that. I personally think that should be at the
> hardware level anyway, why waste the cycles. Secure your network firewalls
> internally to isolate your appliance. If anything, you could ship a software
> based firewall in your appliance (something that uses iptables -- its what
> we had at Yahoo).
>
>
> On Aug 21, 2009, at 10:48 PM, Mark McBride wrote:
>
>> I understand that part.  But how do you prevent people starting a
>> rogue node and adding it to the system?  As I understand it now,
>> anybody can bring up a node, point it at one of the seeds and have it
>> take part in the cluster.  Am I mistaken there?
>>
>>   ---Mark
>>
>> On Fri, Aug 21, 2009 at 10:42 PM, Chris Goffinet<[hidden email]> wrote:
>>>
>>> Thrift is just a cross-platform interface. Using the internal api does
>>> not
>>> mitigate having Cassandra find other nodes.
>>>
>>> -Chris
>>>
>>> On Aug 21, 2009, at 10:39 PM, Mark McBride wrote:
>>>
>>>> There's still the question of inter-node communication though.  One of
>>>> the attractive things to us is the ability to power on another virtual
>>>> appliance and have it auto-discover the other Cassandra nodes.  Is
>>>> this just something outside the scope of the current design?
>>>>
>>>>  ---Mark
>>>>
>>>> On Fri, Aug 21, 2009 at 10:30 PM, Jonathan Ellis<[hidden email]>
>>>> wrote:
>>>>>
>>>>> if your product is jvm based, just use the internal api and don't
>>>>> stzrt the thrift listeners at all.
>>>>>
>>>>> On 8/21/09, Mark McBride <[hidden email]> wrote:
>>>>>>
>>>>>> I'm looking at the potential of embedding Cassandra in one of our
>>>>>> products.  This ships as one or more virtual appliances that runs at a
>>>>>> customer's site, and security is always an issue.  This looks like
>>>>>> mostly a Thrift issue... but I was wondering if anybody on this list
>>>>>> had any thoughts about how you would go about securing Cassandra.  The
>>>>>> best idea I have so far is to try to get THttpClient working (doc
>>>>>> there is very sparse), have Cassandra listen only listen on 127.0.0.1
>>>>>> and have Apache + mod_proxy handle security.  If anybody thinks this
>>>>>> is a dumb way to do it I'm more than willing to listen to alternatives
>>>>>>
>>>>>>  ---Mark
>>>>>>
>>>>>
>>>
>>>
>
>



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp