Security, AAA, and policy management, and multitenancy

[erikh]

Overview

This is a bucket-list of ideas @jainvipin and I sketched out while thinking about this problem.

Basically we want to have a basic RBAC in the sense that each consumer has a role, and roles are used to gain access to things.

Certs are tied to roles. Certs are the unit of authentication. Superusers will have a secondary set of certs to access etcd directly. We are thinking about using notary or atlas to manage this portion.

As mentioned, there is a super-user group that has access to several commands, like:

• volume list-all
• tenant CRUD commands (see below), except get which will be role-scoped.

Tenants are policies which group other policies, and a role. Tenants live above the policy level and scope policies by role. Roles in this iteration will have no place in policies themselves (but it is expected this will change).

Tenant commands:

These are superuser commands:

• tenant upload (upload a tenant policy, similar to policy upload)
• tenant delete
• tenant list

Role-gated commands:

• tenant get

Other commands

All other commands with volmaster access will be role-gated, otherwise etcd certs will be used.

[hsluoyz]

Hi, I'm the author of casbin. It is an authorization library that supports models like MAC, RBAC, ABAC.

Related to RBAC, casbin has several advantages:

1. roles can be cascaded, aka roles can have roles.
2. support resource roles, so users have their roles and resource have their roles too. role = group here.
3. the permission assignments (or policy in casbin's language) can be persisted in files or database.

So please consider using casbin when volplugin implements RBAC security. Also let me know if there's any question:)