PolicyDatabase

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 implicitly 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:

1. (A OR B) AND C = (A AND C) OR (B AND C)
2. (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.

The description field is optional, and can describe the meaning of the Policy.

The version represents the date and time of it's last change (or creation, if no changes are done). When a policy is modified, this field is updated. A copy of the old version should be kept in another table/database in order to make it possible to roll back to a previous version. This mechanism is not detailed in this document.

The enabled field must be set to "TRUE" in order to the policy be verified.

Policies can be optionally scoped in the future. This means that they are only visible and valid for a given Domain or Project. This is important in order to keep them completely isolated for tenant's privacy.

Scope

Scoped policies are only visible and valid for a given Domain or Project. A scope of a policy is composed by a type, which can be "Domain" or "Project", and the value of "Domain id" or "Project id" to be verified. Scopes can optionally have a description.

OR Rule

Each Openstack Policy is composed by one "OR structure". This structure is formed by multiple "AND structures".

When an OR expression is evaluated:

• If the result of one "AND condition" is "TRUE", the access is granted.
• Otherwise, the "AND conditions" continue to be verified.
• If all "AND conditions" are "FALSE", the access is denied.

The OR Rule can have a label, that should be a simple description of its purpose. Usually, it represents the "OR structure of Policy x".

Just like the Policy, the version represents the date and time of it's last change (or creation, if no changes are done). When a OR condition is modified, this field is updated. A copy of the old version should be kept in another table/database in order to make it possible to roll back to a previous version. This mechanism is not detailed in this document.

The enabled field must be set to "TRUE" in order to the OR rule be verified.

AND Rule

Each "OR Rule" is composed by multiple "AND structures". An "AND structure" is formed by multiple conditions.

When an AND expression is evaluated:

• If the result of one "condition" is "FALSE", the result is "FALSE".
• Otherwise, the "conditions" continue to be verified.
• If all "AND conditions" are "TRUE", the result is "TRUE".

The AND Rule can have a label, that should be a simple description of its purpose.

Just like the Policy and the OR Rule, the version represents the date and time of it's last change (or creation, if no changes are done). When a AND condition is modified, this field is updated. A copy of the old version should be kept in another table/database in order to make it possible to roll back to a previous version. This mechanism is not detailed in this document.

The enabled field must be set to "TRUE" in order to the AND rule be verified.

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 type of attribute must have an entry in this table. An attribute has an id and a label. Eg. 1 - Action, 2 - Role, 3 - User_id, ...