Difference between revisions of "PolicyDatabase"
(→Condition) |
(→Condition) |
||
| Line 25: | Line 25: | ||
A value can be a literal (eg. a string or a number) or a variable, which will be interpreted by the Policy Engine. | A value can be a literal (eg. a string or a number) or a variable, which will be interpreted by the Policy Engine. | ||
| − | Attributes can be of different | + | Attributes can be of different types, for instance: |
* Action | * Action | ||
| Line 43: | Line 43: | ||
user_id:%(user_id)s | user_id:%(user_id)s | ||
The "user_id" is also considered as an Attribute type in this database model. | The "user_id" is also considered as an Attribute type in this database model. | ||
| + | |||
| + | Labels are descriptions to the Condition. | ||
| + | For instance, the condition "user_id:%(user_id)s" has the label "owner". | ||
| + | Conditions are not mandatory (can be NULL). | ||
| + | |||
| + | ==== Attribute ==== | ||
| + | Each attribute type must have an entry in this table. | ||
| + | An attribute type has an id and a label. | ||
==== Policy ==== | ==== Policy ==== | ||
Revision as of 15:05, 25 February 2015
Contents
Policy Relational Database Schema for Openstack
Overview
This document describes a relational database schema that stores security policies for Openstack. This schema reflects the current policy engine rules, stored in policy.json files.
Supported Operations
Policies stored in the database will support CRUD operations on policies, and also complex SQL queries, for instance, to find out which are the necessary conditions to perform a given action.
Besides these, two operations will also be supported:
- Import policy.json file into the database: In this operation, policies conflicts will be eliminated. Duplicate rules will also be removed.
- Export policies from database to new policy.json files. These new files will reflect the managed set of rules.
Database Schema
The following figure presents the database schema to store security policies in Openstack.
The purpose of all the tables are described below:
Condition
A condition represents the basic element of a policy. The policy engine will verify if the content of the "attribute" field matches with the "value" one. A value can be a literal (eg. a string or a number) or a variable, which will be interpreted by the Policy Engine.
Attributes can be of different types, for instance:
- Action
Policies in Openstack are assigned to Actions. Actions are represented in the policy.json file by "service:action" entries. They serve as triggers for the Policy Engines to know which rule will be verified. In this database model, they are stored as conditions.
- Role
Roles in Openstack represent Subjects. A user in a domain or project can be directly assigned to roles, or can be part of a group which is assigned to a role. A Role condition will make Policy Engines to verify if the user has a specific role.
- Other types
Despite Openstack uses an RBAC engine, it allows other types of attribute checking in their policies. For instance, the entry below verifies if the user's id matches with the content of the variable user_id. user_id:%(user_id)s The "user_id" is also considered as an Attribute type in this database model.
Labels are descriptions to the Condition. For instance, the condition "user_id:%(user_id)s" has the label "owner". Conditions are not mandatory (can be NULL).
Attribute
Each attribute type must have an entry in this table. An attribute type has an id and a label.
Policy
Represents the Openstack Policy. We can say that all policies in Openstack are combined using the OR logical operator. For instance, we can see entries in a policy.json files as follows: (action: "identity:get_user" AND rule: "admin_required) OR (action: "
