You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Logan Jones <lo...@codescratch.com> on 2022/12/15 18:55:40 UTC

Recommended Permissions

Hello:

I'm working on updating our security posture for our various Accumulo
users. I took a look at the Permissions Page
<https://accumulo.apache.org/docs/2.x/security/permissions> along with the
Java docs for SystemPermission
<https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/SystemPermission.html>
, NamespacePermission
<https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/NamespacePermission.html>,
and TablePermission
<https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/TablePermission.html>
but
still have some questions. Specifically, I would like to know what the
following Permissions are used for:


   - SystemPermssion.GRANT - My assumption is that this means a user with
   these permissions can grant other users various system permissions.
   Effectively if you have this permission you have the ability to have all
   other system permissions.
   - SystemPermission.SYSTEM
   - SystemPermission.OBTAIN_DELEGATION_TOKEN

Also, I'd be interested in your opinions on what permissions I should set
up for the following scenario. I would like to create a root user that can
only manage user/authorizations but cannot read data from any tables, the
root user would be responsible for creating application users which can do
everything but create users and alter authorizations. What permissions
should I set up to make that happen?

Thanks,

- Logan

Re: Recommended Permissions

Posted by Christopher <ct...@apache.org>.
These could be better documented. It's been awhile since I've thought
about these, but I think:

SystemPermission.SYSTEM - basically permits superuser access to
perform most operations. However, this does not allow automatic access
to tables. A user with this permission, however, can grant themselves
permissions to do so.
SystemPermission.GRANT - this is a special permission that allows the
bearer to grant system permissions to other users. This supports the
case where an admin user is granted system permission, but is not
allowed to share those elevated privileges with other users. At one
point, I think this permission could not be granted... so only the
root user could have this, but I think it can be granted now... but it
must be done so explicitly... either way, the important bit is that it
doesn't come with the SYSTEM permission automatically.
SystemPermission.OBTAIN_DELEGATION_TOKEN - that's a special permission
that allows the user to request delegation tokens, which are
time-limited alternatives to Kerberos credentials when you need to
perform an operation... like MapReduce... across a cluster, and don't
want to (or can't) share your user's authentication credentials. This
is because you probably don't want to share your keytab everywhere, or
run kinit interactively on each MapReduce node in a cluster, in order
to run a MapReduce job. Because these allow impersonation of the
requesting user, they are time-limited, and require explicit
permission to obtain.

For your scenario, the root user is already set up that way. You could
create another user and grant them SYSTEM permissions to do the same.
However, any user you create with SYSTEM permissions will be able to
grant themselves READ and/or WRITE permission on any table they like.
If you need more fine-grained access controls, you could plug in your
own `instance.security.permissionHandler`, but that pluggable
component predates our attempt to create stable SPI endpoints, so it
might not be a stable interface, and you may need to update it for new
releases. Stabilizing that as a proper SPI is a medium term goal of
mine, personally, but I'm not sure when it will happen.

On Thu, Dec 15, 2022 at 1:56 PM Logan Jones <lo...@codescratch.com> wrote:
>
> Hello:
>
> I'm working on updating our security posture for our various Accumulo
> users. I took a look at the Permissions Page
> <https://accumulo.apache.org/docs/2.x/security/permissions> along with the
> Java docs for SystemPermission
> <https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/SystemPermission.html>
> , NamespacePermission
> <https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/NamespacePermission.html>,
> and TablePermission
> <https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/TablePermission.html>
> but
> still have some questions. Specifically, I would like to know what the
> following Permissions are used for:
>
>
>    - SystemPermssion.GRANT - My assumption is that this means a user with
>    these permissions can grant other users various system permissions.
>    Effectively if you have this permission you have the ability to have all
>    other system permissions.
>    - SystemPermission.SYSTEM
>    - SystemPermission.OBTAIN_DELEGATION_TOKEN
>
> Also, I'd be interested in your opinions on what permissions I should set
> up for the following scenario. I would like to create a root user that can
> only manage user/authorizations but cannot read data from any tables, the
> root user would be responsible for creating application users which can do
> everything but create users and alter authorizations. What permissions
> should I set up to make that happen?
>
> Thanks,
>
> - Logan