Cisco Panoptica runtime policies govern workload activities in your Panoptica environments. They control which workloads are permitted to run in the environment, and with which other workloads they can communicate while running.

A Panoptica policy is a set of rules, similar to firewall policies and rules. Panoptica policies, however, manage workloads and environments, not IP addresses and ports. A rule to allow a workload to run in an environment remains unchanged if the environment changes from one physical host or cluster to another.

Policy types

Panoptica has several types of runtime policies, which you can use to control workloads in your environments.

Deployment Policy

The Deployment policy controls which workloads can run on a Panoptica environment. It consists of rule statements of the form 'allow workload A in Environment B' or 'restrict workload C in Environment D'. When a workload is deployed to an environment, the Panoptica controller checks the identity, and then checks the policy rules for a rule that allows it to run. If one is found, the workload is allowed. If not, or if there is a rule which restricts it, it is blocked from running.

Rules specify workloads according to name, type, or label.

See Deployment Policy.

Connection Policy

The Connection policy controls connections between workloads in a Panoptica-secured environment, including connections with external applications (that is, applications not running on a Panoptica environment). It consists of rule statements of the form 'allow connections between source S and destination D' or 'restrict connections between source X and destination Y'. In these rules, the source and destination are workloads, environments, or external applications.

Panoptica uses the Istio service mesh to apply the connection policy rules to workloads running on your environments.

Rules can allow or deny connections between workloads, and also enforce encryption between them (implemented in the Istio service mesh).

See Connection Policy.

Cluster Events Policy

The Cluster runtime policy monitors activities on the control planes of your clusters, and enforces rules to permit or block specific types of actions. These can alert, or prevent, unwanted or suspicious actions on resources in your clusters.

See Cluster Event Policy.

Pod Policies

Pod Policies are filter options for Panoptica Deployment Policy Rules, to give you additional filtering choices for workloads, according to properties of the Kubernetes pod on which they are running.

See Pod Security Profiles.

CI/CD Scan Policies

CI/CD Scan Policy control what Panoptica CI/CD plugins in your pipelines do. These plugins scan builds in the pipeline, within the framework of your CI/CD tools, and indicate what vulnerabilities are found in the builds (for example in dependent libraries or packages).

Rules

Panoptica Rules are statements that allow or block workloads from running or communicating. Rules are written in a readable form, to make it easy for you to create and view them.

A deployment rule could look like this:

elastic app can run on Infra

This means that the workload (app) elastic can run on the Infra environment.

A connection rule looks like this:

nginx app can communicate with billing app

Evaluation of Policy rules

Rules are evaluated in the order they appear in the Policies page, from top to bottom, to determine if a workload is allowed to run or communicate with another workload, or blocked. It is therefore important to arrange the rules carefully. General rules that block workloads should be at the bottom of the list, while specific rules that allow workloads should be at the top. Rules that apply to a class of workloads, say using a label, should be below rules that apply to specific named workloads.

You can change the position of rules by dragging them.

View Rules

Navigate to the Policies page and then select one of the tabs, to view rules for these policies. The rules are shown in the order they are evaluated, with the default rule at the bottom.

Rules Symbols

The rules view uses these symbols.

Rule allows the connection

Rule denies the connection (detects it, but does not block it)

Rule blocks the connection

Rule encrypts the connection

Add Rules

See the following pages for details on creating and modifying rules for the different types of policies.

Default Rules

Policies have a default rule, which cannot be removed. The default rules, out of the box, block all workloads from running or communicating. You can modify the definition of the default rules to allow all workloads to run, or to communicate.

The default rules are at the bottom of the list of rules, and are evaluated last (if no other rule before them is found to apply to the workload). You cannot move it up the list.

The default rule is a simpler version of an policy rule. You can set it to block or allow all workloads or connections. You cannot select specific workloads or connections.

For a production environment, the default rule would typically block all workloads or connections. Being the last rule in the policy stack, it would be applied to any workload for which a more specific rule (permitting or blocking) is not found higher in the stack. In a development environment, this rule might permit everything.

The default rule is always applied, and is always the lowest (last) rule in the policy stack. You can only change whether the rule allows or permits.

Modify a Policy

Navigate to the _Policies _page, and one of the policy tabs.
Select the rule to be changed, and click the edit icon on the right.

Make changes to the rule definition, as necessary, and then click FINISH.

Change the position of a rule in a policy

To move a rule to a different position, up or down:

Navigate to the _Policies _page, and select one of the policy tabs.
Select the rule to be changed and, while selected, drag it to the new position, then release.

Enable/disable a rule

You can disable a rule in a policy. When disabled, the rule is not applied to any workload. The rule can be enabled again (after which is applied to workloads). Workloads that were blocked or allowed as a result of the rule may behave differently once it is disabled.

Select the rule to be changed, and click the options menu icon (three dots) on the right.
Select DISABLE (or ENABLE, to enable it again)

Delete a rule

You can delete a rule in a policy. Once deleted, the rule is removed from the list of rules for the policy. Workloads that were blocked or allowed as a result of the rule may behave differently once the rule is deleted.

Select the rule to be changed, and click the options menu icon (three dots) on the right.
Select DELETE.

Enable Policy Application on specific namespaces

You can apply policies selectively to specific namespaces in your clusters . When you deploy the Panoptica Controller in your cluster, you can select which policies are applied to it, using the label
SecureApplication-protected, as follows:

kubectl label namespace $(kubectl get namespaces | awk '{print$1}' | grep -v -e NAME -e kube-public -e kube-system -e istio-system -e portshift) SecureApplication-protected=full  --overwrite

Use the following options for SecureApplication-protected to selectively apply Policies:

SecureApplication-protected=full - Controller will enforce both connection policy and deployment policy in the labeled namespace
SecureApplication-protected=connections-only - Controller will enforce only connection policy in the labeled namespace
SecureApplication-protected=deployment-only - Controller will enforce only deployment policy in the labeled namespace
SecureApplication-protected=disabled - Controller will not enforce connection policy or deployment policy in the labeled namespace