Artica Meta: Policies

Back to Artica Meta

A Meta policy is a configuration template.
You write it once on the Meta server and attach it to agents or to groups of agents.
When you click Apply, Artica Meta sends it to every node it reaches.
It then follows the delivery on each node until the node confirms.

Policies replace the manual work of opening each appliance and repeating the same settings.
They also keep the fleet consistent: a node that joins a group receives the policies of that group.

Policy types

Policies apply to Artica appliances.
A node without Artica receives nothing.
Its entry is rejected with the reason no Artica.

The workflow

Create  ->  Edit the draft  ->  Attach agents or groups  ->  Apply  ->  Check the delivery status

1.

Create the policy

1. Open Artica Meta > Policies.
2. Click New policy.
3. Choose the type and enter a name.

The name must be unique.
The type cannot change later.

2.

Edit the draft

Each policy has a draft and an applied revision.
Every save of the draft increases the revision number.
Saving sends nothing to the nodes.

The list of policies shows a policy as Modified when its draft is newer than the applied revision.
The To apply filter lists these policies.

Each setting and each list is either defined or not defined:

• A defined setting replaces the value of the node.
• A setting that is not defined leaves the value of the node alone.
• A list defined empty is still defined.
  Its effect depends on the type (see "What happens on the node").

Only define what you want to enforce.
Everything else stays under the control of the local administrator.

3.

Attach agents and groups

Open the Targets tab of the policy:

• Attach node adds one agent.
• Attach group adds a group of agents.
• Detach removes a target.

The tab shows how many nodes the policy reaches, directly and through groups.
Cluster slaves appear as excluded: their master receives the policy for them (see "Clusters").

When the policy is already applied, attaching a target sends it right away.
Detaching a target sends the remaining policies of the node again, without the detached one.
When no policy of the type is left, the node is released (see "Releasing a node").
The Proxy type is the exception: detaching sends nothing.

4.

Apply

Click Apply in the list or in the policy.
A confirmation shows the revision and the number of nodes.

Apply freezes the draft as the applied revision.
It then queues every node the policy reaches.
Nodes that already have the same configuration change nothing.

5.

Check the delivery status

The Delivery status tab shows the state of each node.

Click a node to open its report.
The report lists each setting and what the node did with it: applied, unchanged, ignored or refused, with the reason.

Waiting nodes are checked again every 3 minutes.
A node that does not confirm within 30 minutes is queued again.
A rejected node stays rejected.
Fix the cause, then click Send again on that node.
Send again queues the applied revision even without any change.

The queue interval is a setting of the Artica Meta parameters page.

Policies and groups of agents

A node receives every policy attached to it directly and every policy attached to one of its groups.

• A node that joins a group receives the applied policies of that group at once.
• A node that leaves a group no longer receives the policies of that group.
  The same rules as a detach apply.
• Deleting a group detaches its policies from the nodes it contained.

Use groups for what the fleet shares.
Attach a policy to a single agent for what only that machine needs.

Several policies on the same node

A node can receive several policies of the same type.
Artica Meta merges them before sending.
The order is the order of attachment, then the policy number.

• Settings merge key by key.
  The last policy that defines a key wins.
• Lists merge item by item, by name.
  The last policy that defines an item wins with the whole item.
• An item that loses the merge is reported as ignored with the reason conflict in the node report.
• Ordered rule lists (Web filtering, Proxy ACLs, Proxy SSL, Firewall) are concatenated in merge order.
  Each policy keeps its own order.

A typical layout is one group policy for the shared rules and one node policy for local exceptions.

Shared building blocks

Proxy objects

Rules reference Proxy objects: addresses, networks, domains, ports, time ranges, browsers and other ACL types.
Define them once in Artica Meta > Proxy objects.
Every policy type that needs objects reuses them.

Objects are frozen at Apply.
Changing an object updates nothing on the nodes until you apply again each policy that uses it.
An object used by a policy cannot be deleted.

Virtual network cards

Network card names differ from one machine to another.
A policy never names a real interface.
It references a virtual network card, and each node maps it to one of its own interfaces.

Manage them in Virtual network cards.
When a node has no mapping, the setting that uses the card is skipped on that node and the report says so.
The Firewall type is stricter: it sends nothing until every card is mapped.

What happens on the node

The local console is locked

On the node, every part a policy manages becomes read-only.
The local console shows that it is managed by Artica Meta.
The REST API of the node refuses to change it as well.

What the policy does not define stays editable on the node.
For most rule types (Proxy ACLs, Web filtering, Proxy SSL), the local rules also stay.
Meta rules run before them.

The Firewall type works differently.
A defined part replaces the same part on the node, local rules included.

Releasing a node

A node is released when no policy of a type reaches it any more.
This happens after a detach, a policy deletion, or when the node leaves a group.
The node unlocks its console.

What the node keeps depends on the type:

If a node cannot be reached for a release, a local command lifts the lock:

articarest -<type>-meta-release

<type> is one of rdpproxy, webfiltering, dhcp, dnscache, proxypac, activedirectory, ufdbrules, fortiwccp, proxyacls, firewall, sslproxy or siemconnector.

Firewall: confirmation and rollback

A firewall policy can cut the Meta server off from the node.
To avoid locking you out, the node keeps the new rules on probation.
Artica Meta confirms them on its next check.
Without that confirmation the node goes back to its previous firewall on its own.

A rolled-back revision is shown as Rejected.
Meta never sends it again by itself.
Apply again to retry it.

Clusters

Artica clusters replicate most settings from the master to the slaves.
Artica Meta follows that rule: a slave never receives a policy directly.
Its master receives it and replicates it.

• If the master is not managed by Meta, nothing is delivered.
• If the master is itself a slave, nothing is delivered either.
  The cluster is misconfigured.

DHCP and FortiGate WCCP are exceptions.
Their configuration depends on each machine, so every node receives its own policy.

Importing an existing configuration

You do not have to rebuild a configuration that already runs on a node.

Automatic imports run every hour for DHCP, DNS Cache, Proxy PAC and Active Directory.
A node qualifies when the service runs and no policy of that type is attached to it.
Meta creates a policy named after the service and the host name, attaches the node and applies it.
Each node is imported once.
A Reimport button starts it again.

Manual imports are available for Firewall, FortiGate WCCP and DNS Cache (from the agent configuration).
They create the policy and attach the node but do not apply it.
Review the draft, then apply.

Requirements

Each policy type needs a recent agent on the node.
An older agent shows Not supported and the entry waits until the agent is upgraded.

Upgrade the Meta server first, then Artica and the agent on the nodes.
See Upgrade agent versions and Upgrade agent versions from a group.

Policies and tenants

On a Meta server with tenants, each tenant has its own policies.
A tenant policy can only target the nodes and groups of its tenant.
See Tenants.

Known limits

• Two administrators editing the same policy at the same time can overwrite each other.
  The last save wins.
• Renaming a rule recreates it on the node with a new local number.
• A merged configuration is refused when it exceeds the limits of the type, for example 500 rules or 2,000 objects.
  The entry is shown as rejected.