Difference between revisions of "PolicyDatabase"

Revision as of 15:30, 25 February 2015

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.

Policy Database Schema

The purpose of all these tables are described below.

Policy

Represents the Openstack Policy. This is a superset of all conditions that needs to be verified in the whole system.

Policies are stored in the Disjunctive Normal Form (DNF). This means they are converted to simple conditions combined by the AND logical operator, which are combined by the OR logical operator.

Eg.: Suppose C1, C2, C3, C4, C5 and C6 are conditions to be verified, a policy can be written as:

      (C1 and C2 and C3) or C4 or (C5 and C6)

This structure can be represented in the tree below.

                           OR
                      /      |      \
              AND     AND    AND
             /   |   \       |        /    \    
          C1 C2 C3  C4   C5   C6

We can say that all policies in Openstack are combined using the OR logical operator. It means we can see entries in a policy.json files as follows: (action: "identity:get_user" AND rule: "voadmin") OR (action: "identity:list_users" AND rule: "admin_required") OR ...

That makes the Policy entry a super "OR" composed by multiple "AND" entries.

In the example above, you can say a rule can be recursively decomposed in OR or AND statements. But, at the end, they can be transformed into DNF by recursively applying the following rules:

(A OR B) AND C = (A AND C) OR (B AND C) (A OR B) AND (C OR D) = (A AND C) OR (A AND D) OR (B AND C) OR (B AND D)

At the end, all entries in all files will be combined in a super "OR" structure.

OR Rule

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.