Policy Introduction

Apcera Platform provides you with pervasive policy controls to help you secure your system.

You use policy to govern the behavior of workloads and resources in your cluster. To implement policy, you encode your business rules using the policy language. Apcera provides you with various tools for working with policy, including a policy editor for authoring policy, and the APC client for administering policy.

This section introduces you to policy, including typical policy use cases, an overview of how policy works, and a policy example.

Policy use cases

You use policy to inject business rules into your cluster. The policy engine enforces the policy rules on the resources you designate in your policies.

For example, you can create policies to enforce the following business rules:

Business Rule Description
Fine-Grained Access Control Only certain IT personnel can access sensitive databases and perform read and write actions.
Service Bindings Greenfield apps can consume certain PostgreSQL services.
Resource Quotas A developer can use a certain amount of Storage, Networking, Disk, and RAM.
Package Resolution Java production apps should use the JDK 1.8 package.

To learn more about the benefits of the Apcera policy-driven platform for your organization, check out this blog post.

How policy works

Policy is executed by the policy engine. You author policies to control the policy engine.

Policy engine

The policy engine enforces policy. The policy engine is embedded in each system component and can enforce policy on virtually any resource in the cluster, including jobs, packages, stagers, services, service gateways, semantic pipelines, Docker images, and even policy itself, just to name a few.

There are several resources types against which the policy engine can enforce policy. For most resource types, the policy language is exclusively affirmative. This means there is no negative rule assertion or deny permission. For example, if you don't want a user to access a resource, or a job to bind to a service, you simply don't create policy that permits it. This deny-all approach is a key aspect of the system, and is designed to give you maximum control over the resources in your cluster.

Policies

You instruct the policy engine where and what to enforce using policies. A policy is a block of code that conforms to the policy language syntax. A policy includes a single realm and one or more rules.

The following is an example policy:

screenshot

Policy realm

The policy realm is an FQN that defines the resources that the policy applies to. In other words, the realm defines the scope of the policy for the declared resource type.

In the example, the realm is the FQN job::/sandbox/tom. This realm declaration instructs the policy engine to apply the policy rules to all job::/ resources in the sandbox/tom namespace.

Policy rules

Policy rules are if/then constructs that pose a question and, if true (or omitted), instruct the policy engine to take action. Since the policy language is primarily affirmative, action taken by the policy engine is usually a permission grant. Thus, to use a resource in the system, there must be a policy rule that allows it.

In the example, the question part of the rule checks to see if the the Auth Server (auth_server@apcera.me) has issued an access token with the subject name of "tom". If true, the policy engine grants CRUD permissions to user "tom" on job resources in the /sandbox/tom namespace. Without these policy permissions, "tom" cannot create or use jobs in his sandboxed namespace.

Policy example

One common scenario for policy enforcement is package resolution. For example, consider a situation where you want to enforce the use of Ubuntu version 14.04 to satisfy the linux dependency for all jobs in the cluster. In this case you could apply the following policy:

job::/
{
  if (dependency equals os.linux) 
  {
    package.default "package::/apcera/pkg/os::ubuntu-14.04"
  }
}

The realm in this example is the root job::/ namespace, meaning the policy applies to all job resources in the cluster. For each job being staged for deployment, the policy engine checks if the job has the os.linux dependency. If true, the policy engine instructs the job to use the ubuntu-14.04 package to satisfy the dependency.

Although the policy language is primarly affirmative, there may be some exceptions, depending on your viewpoint. Policy for package resolution, for example, limits the packages jobs can use. Likewise policy on the quota resource type limits resource allocation that is otherwise unlimited.

Next steps

Now that you have been introduced to policy, check out the following topics to deepen your understanding of policy.