telark
Guides

Setting up your first protection plan

Walk through plan creation in the dashboard, end to end.

This is the canonical walk-through for opening your first protection window. It covers the dashboard form, what each section maps to on the wire, and the verification steps after the plan activates.

If you have not installed telark yet, start with Getting started → Quickstart.

What you'll need

  • The dashboard accessible at its configured URL.
  • An account with the Contributor role or higher (the Create Plan button is gated by RBAC).
  • At least one application visible in the Applications page — discovery should pick this up automatically within seconds of installing telark.

1. Open the create panel

From Protection Plans → Create Plan, the dashboard opens a side panel with five sections:

  1. Basic info
  2. Scope
  3. Policies
  4. Schedule
  5. Participants

You can switch between sections freely — nothing is persisted until you submit.

2. Basic info

Fill in:

  • Name — short, unique within the cluster. Used in the list page, the violations feed, and the rendered Kyverno policy names. Stick to lowercase / hyphens.
  • Description — one-line context. Renders on the detail page and in audit logs.
  • Severity (optional) — UI annotation. Helps you sort plans by importance later; does not affect cluster behaviour.
  • Priority (optional) — integer used by the list-page ordering when multiple plans overlap. Higher = earlier in the list.

3. Scope

Pick applications or namespaces:

  • applications — the picker shows every application discovered in the cluster. The plan will resolve to the live set of workloads in each application at activation time.
  • namespaces — the picker shows every non-excluded namespace. The plan will target every resource in each namespace.

Some templates only support applications scope. The picker shows a warning if a chosen template is incompatible with the chosen scope. Example: block-replica-scaling only makes sense in the application scope.

4. Policies

Add one or more policies to the plan. Each row asks for:

  • Template — pick from the catalog. The picker is filtered to templates compatible with the current scope.
  • Parameters — only shown for templates that declare them. Templates with string-array params (e.g. block-image-tags.tags) accept a comma-separated list which the dashboard parses into string[].

Above the rows, pick a plan-wide Mode:

  • audit — log violations, do not block admission.
  • enforce — reject admission on violation.

Mode is per-plan, not per-policy. Splitting audit + enforce across templates inside one plan is on the ideas list — today, create two plans.

5. Schedule

Pick Permanent or Time range:

  • Permanent — plan runs until cancelled.
  • Time range — pick startAt and endAt (RFC3339). The controller activates the plan at startAt and terminates it at endAt. Both are honoured at the next controller tick (default 31s).

For a first plan, time range is the right call. Set the window short — 10 to 30 minutes — so you can watch the full lifecycle.

6. Participants

The participants section is a multi-select on users / groups. It populates the plan's participantsIDs field and renders on the detail page as the "owners" badge. Today this field is informational. RBAC enforcement on cancel / reactivate is on the ideas list.

7. Submit

Hit Create Plan. The dashboard posts to POST /protection-plans/prepare. Three things happen server-side:

  1. The discovery service validates the payload (template params, scope membership, time-range consistency).
  2. The exporter persists the ProtectionPlan custom resource.
  3. The plan's phase is set:
    • scheduled if startAt is in the future.
    • active if timeMode=permanent or startAt ≤ now — the applier deploys the Kyverno policies in the same call.

You land back on the detail page for the new plan.

8. Verify the plan

The detail page renders:

  • Overview — identity, mode, lifecycle metadata.
  • Scope — resolved application / namespace list.
  • Policies — the templates you picked with their parameters.
  • Participants — the users / groups you selected.
  • Health — Unknown until activation. After activation, runs the cluster-truth compute and resolves to Healthy, Drifted, or Degraded.
  • Violations — the live feed once active.

Check:

  1. The phase moves from scheduled → active within one controller tick (~31 seconds) of startAt.
  2. Health goes to Healthy within the next tick once policies are deployed.
  3. If you trigger a violating change inside the scope (e.g. try to delete a Deployment in a plan with block-delete enforced), the cluster's API server rejects the change with the policy's message — and the Violations tab on the plan grows by one row on the next refresh.

What to do next

  • Watch the plan terminate at endAt. Phase moves to terminated, the applier cleans up the deployed Kyverno policies, health returns to Unknown.
  • Try Duplicate on the terminated plan — it clones the configuration into a new draft with regenerated IDs.
  • Try Reactivate on a cancelled plan — restores prior intent and goes back through scheduled → active.

Configuring Google OIDC

Wire Google Workspace as an additional sign-in provider on top of passkeys.

Performing your first rollback

Trigger a rollback and verify the cluster returns to a known-good state.

On this page

What you'll need1. Open the create panel2. Basic info3. Scope4. Policies5. Schedule6. Participants7. Submit8. Verify the planWhat to do nextRelated