Protection plans

This page is the concept primer for protection plans. The wire surface — endpoints, payloads, the lifecycle endpoints — lives in Features → Protection plans. Start here if you want to understand the mental model before reading the API.

The primitive

A protection plan is a scoped, time-bounded set of admission policies with cluster-truth health. It is the unit telark is built around. Three things define it:

Scope. A plan applies either to a list of discovered applications or to a list of namespaces. The plan resolver translates that scope into the actual workloads at activation.
Templates. A plan selects one or more policy templates from the built-in catalog. Each template is a parameterised admission rule.
Window. A plan is either permanent (active until manually cancelled) or time-ranged (active only between startAt and endAt).

When a plan is active, the discovery service's applier has deployed the rendered policies into your cluster. When it terminates, those policies are removed. There is no permanent mark on the cluster outside the window.

Why "protection plan" instead of "policy"

Most Kubernetes policy tools think of policy as a library you maintain. You write or import policies, they run forever, and the operational concern is keeping the library tidy.

telark treats policy as a window you open:

You pick from a catalog of templates rather than authoring policies.
You scope to applications, not just clusters or namespaces.
You bind a time range to the protection itself, not to a separate scheduler.
You see health and drift live, against the cluster's own reported state.

The framing matters because the operational events that justify admission policy — release freezes, incident windows, compliance audits, retention holds — are bounded in scope and time. The plan primitive lets you express both bounds at once.

What a plan is not

Not a CI gate. Plans run at admission, inside the cluster. They cannot fail your pipeline; the cluster can refuse a write.
Not a static catalog. Plans expire. Permanent plans can be cancelled. Reactivation restores prior intent.
Not a custom-policy authoring tool. Today the catalog is curated. Customer-authored templates are on the ideas list, not shipped.

Lifecycle, at a glance

Phase	What happens
`draft`	The plan exists in the CRD store but has no schedule and no admission effect.
`scheduled`	The plan has a `startAt` in the future. No admission effect yet.
`active`	The applier has deployed the rendered admission policies. Health and violations are live.
`terminated`	The window ended (`endAt ≤ now`). The applier cleaned up. Phase is terminal.
`canceled`	A manual cancel moved the plan out of `scheduled` or `active`. The applier cleaned up.
`failed`	Activation failed. Partial state may exist; manual reactivate to retry.

The lifecycle is owned by an in-cluster controller running on a configurable tick — by default 31 seconds. The controller is the only component that flips a plan to active or terminated; the API enforces the rest of the transitions.

How drift becomes detectable

Drift detection is what separates "policy declared" from "policy running". telark's health compute:

Lists every Kyverno policy labelled by the plan's ID.
Checks each declared policy is present, ready, and configured for the plan's mode (audit or enforce).
Flags an unexpected labelled policy as drift even if every declared one is healthy.

The plan's health is therefore the cluster's word, not the API's. If someone hand-edits a deployed policy, the next health tick catches it.

The participant model

A plan has a participantsIDs field that lists the user / group IDs responsible for it. Today this drives the dashboard's "who owns this plan" badge. The ideas list includes wiring participantsIDs to RBAC so that only listed participants can cancel or reactivate a plan. Treat the field as visible today, enforced later.