You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Sean Busbey (JIRA)" <ji...@apache.org> on 2014/03/13 17:13:46 UTC

[jira] [Commented] (ACCUMULO-1165) Use a unique SystemToken (credentials) for each server instance (TServer, etc.)

    [ https://issues.apache.org/jira/browse/ACCUMULO-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933470#comment-13933470 ] 

Sean Busbey commented on ACCUMULO-1165:
---------------------------------------

What does this get us over properly integrating Kerberos support into our services?

Kerberos is already the standard way that multi-service systems handle mutual authentication (both in general and specifically within Hadoop). It's already had far better analysis done than anything we come up with and operators that need secure set ups are more likely to be familiar with it (or to already have established a support path for dealing with it).

> Use a unique SystemToken (credentials) for each server instance (TServer, etc.)
> -------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-1165
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1165
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>
> Each component should use unique system credentials, and those credentials should only be valid while a tablet server (or other component) holds a lock in zookeeper.
> This behavior more accurately reflects the security model for system components, and may be able to help reduce or eliminate the possibility of multiple-assignment. It could also help prevent problems of other "half-dead" components that have lost their lock (such as a master), by adding an authentication check for the master in the tablet servers.
> It's important to realize that this ticket doesn't necessarily improve security (any component with access to the configuration secret can fake it the lock ID), but it does provide additional sanity checks by authenticating individual system components, and improves the handling of failure conditions.



--
This message was sent by Atlassian JIRA
(v6.2#6252)