Protection plans, scoped to discovered applications, watched from inside the cluster.
The whole feature surface — plan lifecycle, scope resolution, templates, scheduling, health, violations, and the operational core that holds it all up.
Time-bounded admission policies, scoped to real applications.
A plan binds a set of policy templates to a scope (applications, namespaces, or both), a mode (audit or enforce), and a time range. Phase transitions are owned by an in-cluster controller running on a 31-second tick by default; deployment of cluster-side policies is handled by an applier that labels every policy with the plan ID for clean lifecycle.
- Lifecycle endpoints: prepare, update, cancel, reactivate, duplicate, delete.
- Phases: draft → scheduled → active → terminated, with cancel/reactivate side paths.
- Per-plan mode flag — audit or enforce — flips the cluster-side failureAction in lockstep.
- Plans are persisted as ProtectionPlan custom resources owned by the exporter service; discovery never writes the CRD directly.
Pin the plan to apps. Not just namespaces.
Discovery groups workloads into applications continuously through Kubernetes informers, with bursts coalesced through a Redis stream so a single deploy does not flood the system. The plan resolver translates application IDs into the live set of workload references that the applier targets at activation.
- Scope choice per plan: applications, namespaces, or both — depending on what each template supports.
- Resolver returns the primary namespace and the resource refs for every requested application ID; missing IDs are reported separately so the API can surface a precise error.
- Discovery scales horizontally via Redis leader election and consumer groups; followers handle force-sync markers.
- Namespace exclusion is enforced at the listing layer — excluded namespaces never enter any plan's scope.
Nine built-in templates. Parameterised where it matters.
telark ships a curated template catalog of admission rules. Each template names a Kubernetes-side guarantee it enforces, declares the scopes it supports, and exposes only the parameters that change the behaviour — no YAML hand-rolling.
- block-create / block-update / block-delete — broad freezes within scope.
- block-image-types — glob patterns for blocked registries or images.
- block-image-tags — reject specific tags like latest or snapshot.
- block-replica-scaling — applications only; pins Deployment and StatefulSet replicas.
- block-storage-changes — locks PVC and volume mutations.
- block-config-secret-resource-changes — rejects updates and deletes on ConfigMaps and Secrets.
- block-workload-config-mount-changes — freezes mount and env-source references on workloads.
Protection on a clock. Reversible by design.
Permanent plans run until cancelled; time-range plans activate at startAt and terminate at endAt. The controller transitions phases on a configurable tick (PROTECTION_PLAN_TICK_INTERVAL_SEC; default 31 seconds), so windowed protection lines up with the operational events that justify it — release cuts, incident freezes, audit periods, retention holds.
- timeMode: permanent or time_range.
- timeRange.startAt / timeRange.endAt drive controller-led activation and termination.
- Manual cancel and reactivate are first-class — no need to wait for the next tick when you mean now.
- Duplicate clones a plan into a new draft with regenerated IDs.
Cluster-side audit, not user-trust audit.
Health is computed by reading the actual policy resources that live in your cluster, not by trusting the API write. The compute walks every policy labelled by plan ID, checks for presence, readiness, and matching failureAction, and watches for unexpected labelled policies the plan never declared.
- Healthy — every declared policy present, ready, and configured for the plan's mode.
- Drifted — declared policy missing, unexpected labelled policy present, or failureAction tampered with.
- Degraded — policy is present but the engine has not reconciled it yet.
- Unknown — plan not yet active; no false confidence.
- Result is persisted back to the ProtectionPlan CRD via a PATCH so the dashboard reads a single source of truth.
What the cluster caught, sorted newest first.
Violations are sourced from the cluster's policy reports surface in every namespace within the plan's scope, filtered down to the policies your plan actually deployed. The feed is the daily-driver view operators reach for first.
- Default page size 50, max 200, sorted by timestamp newest first.
- Optional result filter: pass, fail, warn, error, skip.
- Each violation carries policy, rule, namespace, resource kind/name/namespace, and the engine's message.
- Backed by the cluster's PolicyReport CRs — same source of truth the engine itself reports against.
The hygiene table stakes — included, not headlines.
telark ships passkey-first auth, OIDC, RBAC as CRDs, classified change history with pre-change snapshots, one-call rollback for thirteen Kubernetes kinds, Redis-backed notifications, and a NATS topic for change events. These are core capabilities — required for the product to be usable — but they are not what telark is selling.
- Passkey + OIDC auth; users, groups, and roles as Kubernetes custom resources.
- Snapshots cover Deployment, StatefulSet, DaemonSet, ConfigMap, Secret, PVC, Service, Ingress, CronJob, Job, HPA, VPA, NetworkPolicy.
- Retention bounded — five versions per scope by default, configurable, pruned automatically.
- Notifications via Redis pub/sub with per-user mark-read state; change events on telark.applications.update.
- AI enrichment is optional and disabled by default — not a flagship.
Open your first protection window.
Helm install. Discovery picks up your apps. POST one plan. The cluster does the rest.