Discover your applications, then decide what can change them — and when.
The whole feature surface — plan lifecycle, application scope, templates, scheduled windows, cluster-truth 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 ready-made 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 — Prevents creation of any resource within the scope.
- block-update — Prevents updates to any resource within the scope.
- block-delete — Prevents deletion of any resource within the scope.
- block-image-types — Rejects container images matching the patterns you set.
- block-image-tags — Rejects specific tags — latest, dev, snapshot.
- block-replica-scaling — Pins Deployment and StatefulSet replica counts.
- block-storage-changes — Locks PersistentVolumeClaims and volume definitions.
- block-config-secret-resource-changes — Rejects updates and deletes on ConfigMaps and Secrets.
- block-workload-config-mount-changes — Freezes volume mounts and env-source references.
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 short, configurable tick, 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, Google SSO, RBAC as CRDs, classified change history with pre-change snapshots, one-call rollback for thirteen Kubernetes kinds, and in-app notifications. These are core capabilities — required for the product to be usable — but they are not what telark is selling.
- Passkeys and Google SSO; 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.
- In-app notifications with per-user mark-read state, plus a change-event stream for downstream consumers.
- AI insights per application are optional and disabled by default.
Open your first protection window.
One Helm command. Discovery picks up your applications. Pick a template, pick a window. The cluster does the rest.