Policy management notes

This section contains information on:

Authorization policies

Keep in mind the following information about authorization policy management:

  • The system ships with default policies that become active if you do not customize policies. Authorization evaluation is distributed per tenant throughout the cluster.

  • Policies are editable using the REST APIs.

  • Deny policies have precedence over accept policies.

  • Policy failures are tracked by audit logs.

For additional policy details, see policy enforcement in the online programming documentation available by selecting System > Documentation > Orchestrator.

 For developers that want to restrict domain properties data from other users, see Configuring user restrictions to display sensitive information in domain properties.

The following code shows an example of a default REST API authorization policy. This policy limits the creation of new domains to users with the admin role.

:
Policies:
},{
"id" : "73912345-bdb8-4249-bd47-717455278580",
"policyType": "authorization",
"name": "CreateDomain",
"authRealm": "Market",
"tenantId": "956345eb-0949-3aa2-8575-72ad9d5f9a61",
"description": ”Create a Domain",
"conditionId": "63912345-bdb8-4249-bd47-818455278570",
"action": "Accept"
},{
Conditions:
},{
"id" : "63912345-bdb8-4249-bd47-818455278570",
"name": "role_is_admin",
"tenantId": "956345eb-0949-3aa2-8575-72ad9d5f9a61",
"description": "User must have admin role",
"definition" : "user:role == "admin""
},{

The following table contains the authorization policy applicable attributes for the previous default policy example.

Table 1. Authorization policy attributes example
Attribute Name Description

Authorization policy

id

Policy identifier

name

Policy name

authRealm

Defines the REST API category to match (for example, Market or Authentication)

tenantID

Defines the specific tenant ID for whom the policy applies

description

(Optional) Defines the policy needing evaluation

conditionId

Provides a reference to the matching logic required

action

Defines the messaging action to be taken if the conditions are met (accept or deny)

Authorization condition

id

Matches the authorization policy conditionID

name

Identifies the name given to the condition

tenantID

Defines the specific tenant ID that matches the condition

description

Defines what this condition is about

definition

Provides actual condition logic
Event policies

The following figure depicts a typical event policy workflow and the sequence of events. A description of the workflow follows.

event policy workflow.png
Figure 1. Blue Planet event policy workflow

The event policy workflow follows.

  1. Workflow Engine executes a TOSCA template that implements a service and:

    1. Creates a resource on an external system.

    2. Installs an event policy (via a Monitor resource) to monitor the external resource for specific events (for example, an alarm).

  2. External system raises the alarm on the external resource.

  3. Policy Manager sees the alarm in the alarm event stream.

  4. Event policy is evaluated and its condition logic is met. It triggers the action to send a message back to the Orchestrator to update the service about the alarm.

  5. The update of the service triggers such activity as autohealing and autoscaling.

For additional policy rules, see the online programming documentation available by selecting System > Documentation > Orchestrator.

Create event policy overview

There are two ways to create event policies:

  1. The most common method is to use the REST API to create a Monitor resource in a TOSCA service template. This method installs an event policy.

    The following is an example declarative template that creates a monitor that triggers the patching of another resource when an internal Heartbeat event occurs.

    For detailed policy manager code attributes and values, see the online programming documentation available by selecting System > Documentation > Orchestrator.

    serviceTemplates {
MonitorExample {
title =  Declarative Monitor Example
description = Declarative Monitor Example
implements = test.resourceTypes.MonitorExample

resources {

resource1 {
type = test.resourceTypes.ExampleResource
properties {
field1 = {getParam = field1}
}
activateAfter = [ ]
}

monitor {
type = tosca.resourceTypes.Monitor
properties {
topic = "com.cyaninc.bp.events"
condition = """event:$._type == "com.cyaninc.bp.events.Heartbeat" """
actionInfo = {
transport = HTTP
httpTransportInfo = {
method = PATCH
url = {join = [ "/", {getContext = uri}, "market/api/v1/resources",
{getResourceId = resource1}]}
headers = [
{ name = bp-user-id, value = {getContext = userId} }
{ name = bp-tenant-id, value = {getContext = tenantId} }
{ name = bp-role-ids, value = {getContext = roleIds} }
]
body = {
contentType = "application/json"
contents = """{"properties": {"field1":
"[[event:$.sequenceNr]]"}}"""
}
}
}
}
activateAfter = [ resource1 ]
terminateBefore = [ resource1 ]
}
}
}
}

  2. Create an event policy that is not tied to a service using the REST API. This guide does not describe this use case.

results matching ""

    No results matching ""