Admission Controllers

As a Kubernetes-native platform, Veeam Kasten manages its configuration and operations entirely through Kubernetes resources. All Kasten APIs including Policies, Profiles, Actions, and RestorePoints are resources in the Kubernetes API. This means the standard Kubernetes governance toolchain — including admission webhooks, Validating Admission Policy, and third-party policy engines such as Kyverno and Open Policy Agent (OPA)/Gatekeeper — can be used to govern Kasten data protection operations the same way it governs any other activity in the cluster.

With admission control policies, organizations can enforce requirements that go beyond what RBAC alone can express. Common use cases include:

• Preventing creation of a backup Policy unless it excludes sensitive resource types, such as Secrets.
• Requiring that the target namespace of a RestoreAction matches a naming convention, such as sharing a prefix with the namespace from which the backup was taken.
• Excluding sensitive resource types from RestoreActions by mutating the restore request's filters.
• Requiring that manual RunAction of a policy specify an expiration to prevent orphaned backup data.
• Blocking deletion of RestorePoints that have not yet exceeded a required retention period.

Technical Preview

Admission controller support for Kasten aggregated API resources (Actions and RestorePoints) is a Technical Preview capability and must be explicitly enabled. By default, all admission policies targeting Kasten aggregated API resources are not seen or processed by the relevant controller.

The functionality, configuration options, and behavior described in this section may change in future releases and should not be relied upon in production environments. Review the limitations prior to enabling this capability.

Enabling Aggregated API Admission Controller Support

To enable admission controller processing for Veeam Kasten aggregated APIs, set the following value when installing or upgrading the Kasten Helm chart:

--set services.aggregatedapis.admissionController=true

warning

Enabling this capability immediately activates any existing admission policies that match Kasten aggregated API resources, including policies that were previously written but silently never enforced. Because internally created resources (such as BackupAction resources created by scheduled policy runs) are also evaluated, an overly broad policy can cause scheduled backups, restores, or retirements to start failing. Before enabling enforcement, review existing policies that match kio.kasten.io API groups and consider running them in a non-blocking mode first (for example, Kyverno's Audit failure action or a ValidatingAdmissionPolicy Warn validation action) to observe policy impact.

To enable support for the Kubernetes Mutating Admission Policy feature for Veeam Kasten aggregated APIs, set the following value when installing or upgrading the Kasten Helm chart:

--set services.aggregatedapis.mutatingAdmissionPolicy=true

Note

Mutating Admission Policy is enabled by default in Kubernetes v1.34 or later. Prior Kubernetes versions require enabling the relevant cluster feature gate.

Technical Preview Limitations

When enabled, admission control for Kasten aggregated API includes the following known limitations:

• Operations performed entirely within Kasten services may not pass through the aggregated API and therefore are not evaluated by admission policies.
• Kasten aggregated API resources do not support updates after creation; policies should target CREATE and DELETE operations.
• Error reporting for denied operations in the Kasten dashboard is still being improved; some denied operations may surface generic error messages.
• Auditing of internally created resources is performed against the dry-run request, which is subject to the request attribution caveats described in the audit documentation.

Supported Resources

When enabled, admission control applies to the Kasten resources served by the aggregated API server, including:

API Group	Resources
actions.kio.kasten.io/v1alpha1	BackupAction, BackupClusterAction, BatchRestoreAction, CancelAction, ExportAction, ImportAction, MigrateFCDAction, ReportAction, RestoreAction, RestoreClusterAction, RetireAction, RunAction, StageAction, UpgradeAction, ValidateAction
apps.kio.kasten.io/v1alpha1	Application, ClusterRestorePoint, RestorePoint, RestorePointContent
dr.kio.kasten.io/v1alpha1	KastenDRRestore, KastenDRReview
repositories.kio.kasten.io/v1alpha1	StorageRepository
vault.kio.kasten.io/v1alpha1	Passkey

CRD-based Kasten resources (such as Policy and Profile) are handled directly by the Kubernetes API server and are subject to admission control regardless of this setting.

How It Works

Requests made directly against the aggregated API, for example creating a RestoreAction via kubectl or through the Kasten dashboard, are evaluated by the matching admission policies before the resource is persisted. If a validating policy denies the request, the operation fails and the policy's failure message is surfaced to the caller and, where applicable, in the Kasten dashboard. Mutations from mutating policies are applied to the resource before it is stored.

Some resources are created indirectly by Kasten services as part of normal operation. For example, running a backup policy creates BackupAction resources, and deleting a RestorePointContent creates a RetireAction. Kasten validates these internal operations against admission policies using Kubernetes dry-run requests before persisting the resources.

warning

Because internal operations are validated via dry-run, admission policies written against Kasten resources must be safe to evaluate in dry-run mode. Webhooks must declare sideEffects: None or sideEffects: NoneOnDryRun; otherwise, the dry-run request will not be sent to the webhook and the operation will fail.

When writing policies, keep in mind that a policy on a low-level resource can affect higher-level operations. For example, a validating policy that blocks RetireAction creation will also cause deletion of the corresponding RestorePointContent to fail, and a policy that blocks BackupAction creation will cause scheduled policy runs to fail. Consider exempting Kasten system service accounts from policies that are only intended to constrain end users.

Example: Blocking User Deletion of RestorePoints

The following Kyverno ClusterPolicy blocks deletion of RestorePoint and RestorePointContent resources by regular users, while still allowing Kasten's own service accounts (and cluster-admin) to delete them as part of normal retention and retirement processing. Matching on the system:serviceaccounts:kasten-io group avoids having to enumerate individual Kasten service accounts.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-rp-deletion-users
  annotations:
    policies.kyverno.io/title: Block User RestorePoint Deletion (Allow K10 System Accounts)
    policies.kyverno.io/description: >-
      Blocks deletion of RestorePoints by regular users while allowing any K10 service
      account (system:serviceaccounts:kasten-io group) and cluster-admin to delete.
      Using the namespace-scoped group avoids having to enumerate individual SAs.
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: deny-user-restorepoint-deletion
    match:
      any:
      - resources:
          kinds:
          - apps.kio.kasten.io/v1alpha1/RestorePoint
          - apps.kio.kasten.io/v1alpha1/RestorePointContent
          operations:
          - DELETE
    exclude:
      any:
      # Any SA in the kasten-io namespace (covers executor-svc, catalog-svc, and any future K10 SAs)
      - subjects:
        - kind: Group
          name: system:serviceaccounts:kasten-io
      # Break-glass: cluster-admin can still delete
      - clusterRoles:
        - cluster-admin
    validate:
      message: >-
        [policy-02] Only K10 service accounts (system:serviceaccounts:kasten-io) or
        cluster-admin may delete RestorePoints. User deletions are blocked.
      deny: {}