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 filein its configuration file, /etc/barbican/barbican.conf. Typically this file isnamed policy.yaml and it is stored in /etc/barbican/policy.yaml.
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 anotherRULE_STATEMENT or a MATCH_STATEMENT:
RULE_STATEMENT: RULE_STATEMENT or MATCH_STATEMENTMATCH_STATEMENT is a set of identifiers that must matchbetween the token provided by the caller of the API and the parametersor 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 musthave either the admin or creator role in your token.
Warning
The Key Manager service scopes the ownership of a secret at theproject level. This means that many calls in the API will perform anadditional check to ensure that the project_id of the token matches theproject_id stored as the secret owner.
Default Policy
The policy engine in OpenStack is very flexible and allows forcustomized policies that make sense for your particular cloud. The KeyManager service comes with a sample policy.yaml file whichcan be used as the starting point for a customized policy. The samplepolicy defines 5 distinct roles:
- key-manager:service-admin
-
The cloud administrator in charge of the Key Manager service. Thisuser has access to all management APIs like the project-quotas.
- admin
-
Project administrator. This user has full access to all resourcesowned by the project for which the admin role is scoped.
- creator
-
Users with this role are allowed to create new resources and can alsodelete resources which are owned by the project for which the creatorrole is scoped. They are also allowed full access to existing secretsowned by the project in scope.
- observer
-
Users with this role are allowed to access to existing resources butare not allowed to upload new secrets or delete existing secrets.
- audit
-
Users with this role are only allowed access to the resourcemetadata. So users with this role are unable to decrypt secrets.
Access Control List API
There are some limitations that result from scoping ownership of asecret at the project level. For example, it is not possible to grant auser access to a single secret, as granting a role on a project wouldallow access to all all secrets owned by that project.
Additionally, there is no easy way to upload a private secret (i.e. asecret that only you have access to) without creating a new project forwhich only you have roles assigned on it.
To address these limitations the Key Manager service includes anAccess Control List (ACL) API. For full details see the ACLAPI User Guide