Yes, that's certainly one option. You could develop a Query Service Layer
which wraps Accumulo's API, implements its own authorization policy, and
then uses a singular set of credentials to authenticate to Accumulo.

Personally, I call this the "Database User" approach, since it is a common
strategy when using traditional relational databases where a set of
database credentials are stored in an application's own configuration
somewhere, and the application implements its own security policies within
the application which are separate from the database credentials.

Another option is to make use of Accumulo's "pluggable" Authentication and
Authorization interfaces and to provide your own implementation on your
class path. See:
https://accumulo.apache.org/1.7/accumulo_user_manual.html#_pluggable_security
https://accumulo.apache.org/1.7/accumulo_user_manual.html#_instance_security_authenticator
https://accumulo.apache.org/1.7/accumulo_user_manual.html#_instance_security_authorizor
https://accumulo.apache.org/1.7/accumulo_user_manual.html#_instance_security_permissionhandler

Note: this is an advanced feature, and it may require substantial
investment to develop and maintain a secure implementation suitable for
your situation.
On Thu, May 24, 2018 at 11:36 AM mhd wrk <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB