ce6336f393
Modified policy and tests to verify this change. As per this change, user with 'creator' role can delete a secret or a container as long as that user has initially created that secret or container. There is still a difference between 'admin' role and 'creator' role behavior around delete operation. With this change, users with 'creator' role cannot delete any other user's secret/container in same project while user with 'admin' role can do that. Updated role docs to reflect this behavior. Change-Id: I53e5529ed34ac4acc76348ca0431cb3de7934b6d
3.2 KiB
Access Control
Role Based Access Control (RBAC)
Like many other services, the Key Manager service supports the
protection of its APIs by enforcing policy rules defined in a policy
file. The Key Manager service stores a reference to a policy JSON file
in its configuration file, /etc/barbican/barbican.conf. Typically this file is
named policy.json and it is stored in /etc/barbican/policy.json.
Each Key Manager API call has a line in the policy file that dictates which level of access applies:
API_NAME: RULE_STATEMENT or MATCH_STATEMENTwhere RULE_STATEMENT can be another
RULE_STATEMENT or a MATCH_STATEMENT:
RULE_STATEMENT: RULE_STATEMENT or MATCH_STATEMENTMATCH_STATEMENT is a set of identifiers that must match
between the token provided by the caller of the API and the parameters
or target entities of the API in question. For example:
"secrets:post": "role:admin or role:creator"indicates that to create a new secret via a POST request, you must have either the admin or creator role in your token.
Warning
The Key Manager service scopes the ownership of a secret at the project level. This means that many calls in the API will perform an additional check to ensure that the project_id of the token matches the project_id stored as the secret owner.
Default Policy
The policy engine in OpenStack is very flexible and allows for
customized policies that make sense for your particular cloud. The Key
Manager service comes with a sample policy.json file which
can be used as the starting point for a customized policy. The sample
policy defines 5 distinct roles:
- key-manager:service-admin
-
The cloud administrator in charge of the Key Manager service. This user has access to all management APIs like the project-quotas.
- admin
-
Project administrator. This user has full access to all resources owned by the project for which the admin role is scoped.
- creator
-
Users with this role are allowed to create new resources and can only delete resources which are originally created (owned) by them. Users with this role cannot delete other user's resources managed within same project. They are also allowed full access to existing secrets owned by the project in scope.
- observer
-
Users with this role are allowed to access to existing resources but are not allowed to upload new secrets or delete existing secrets.
- audit
-
Users with this role are only allowed access to the resource metadata. So users with this role are unable to decrypt secrets.
Access Control List API
There are some limitations that result from scoping ownership of a secret at the project level. For example, there is no easy way for a user to upload a secret for which only they have access. There is also no easy way to grant a user access to only a single secret.
To address this limitations the Key Manager service includes an Access Control List (ACL) API. For full details see the ACL API User Guide