This is unreleased documentation for Policy Manager 1.26-next.

SUSE® Rancher Prime: Admission Policy Manager (Kubewarden) use cases

These are a few example use cases for SUSE® Rancher Prime: Admission Policy Manager (Kubewarden)'s personas.

Case A: As a Kubernetes operator, I want to ensure my cluster is safe and compliant.

I deploy SUSE Admission Policy Manager and its default configuration with its kubewarden-defaults Helm chart, in the kubewarden Namespace. This deploys a default PolicyServer and recommended ClusterAdmissionPolicies in the kubewarden namespace, solely under the control of the Kubernetes operator.

As an operator, I can add more PolicyServers under a managed Namespace (such as kubewarden) to distribute load and fault tolerance.

Operators can deploy more ClusterAdmissionPolicies and ClusterAdmissionPolicyGroups. These check all the Kubernetes resources, for any type of operation (GET, CREATE, UPDATE, PATCH, DELETE, PROXY). This ensures operations into the cluster are safe and compliant.

These include:

  • security

  • compliance (to industry standards or company regulations)

  • resource optimization (via mutating policies)

  • governance of Kubernetes environments (via labels and naming conventions)

  • best practices

  • image verification

Security expectations change over time. Previously correct deployments in the cluster may no longer be so. Yet SUSE Admission Policy Manager has already accepted those operations in the cluster. In these situations, the operator can deploy the Audit Scanner feature, a CronJob that runs periodically and evaluates the existing resources in the cluster. This checks the cluster is safe and compliant even over time.

The operator can configure policies in monitor mode instead of protect mode, to learn from the state of the cluster without blocking operations.

Operators can receive information from policies and the SUSE Admission Policy Manager stack by consuming logs and OpenTelemetry information for metrics and tracing.

Case B: As a Kubernetes operator, I want to provide a framework to my Kubernetes users so they can self-service in their Namespaces.

As an operator, I deploy SUSE Admission Policy Manager as in Case A for a set of policies of my choosing. This provides me with a safe baseline in the cluster, that other users can’t evade.

As well as Case A, I have different personas per Namespaces: perhaps teams, team administrators, test deployments, and others. I allow each Namespace administrator to self-service by letting them deploy PolicyServers in their Namespace, along with namespaced AdmissionPolicies and AdmissionPolicyGroups. This architecture means that they’re in control of their PolicyServer and policies. The policies only apply to their Namespace, and they constrain resource usage to their Namespace.

It also permits the operator to segregate noisy tenants, reserving performant PolicyServers for those tenants and tasks that need high throughput and low latency, for example.

Case C: As a policy author, I want to use the tools and languages that I know to write new policies.

SUSE Admission Policy Manager achieves this by supporting any language that compiles to WebAssembly as possible target languages for policies. This means that policy authors can reuse their workflows (git, CI, editors, peer reviews, etc.), and tools: languages, language libraries, testing harnesses and frameworks, etc.

It permits re-using Domain Specific Languages (like Rego, CEL, Kyverno’s YAML+macros) or general-purpose languages (like Go, Rust, C#, Javascript, any that compiles to Wasm). SUSE Admission Policy Manager provides SDKs for a few languages as first-class support.

SUSE Admission Policy Manager policies can be simple or complex context-aware policies. Context-aware policies are also used to interface with separate workloads (for example, to obtain information from an image scanner long-running service).

Case D: As a system integrator, I want to re-use SUSE Admission Policy Manager as part of my security and compliance solution.

As a system integrator, I want to re-use SUSE Admission Policy Manager, and possibly re-use other solutions by including them in SUSE Admission Policy Manager.

As a system integrator, I can reuse parts of SUSE Admission Policy Manager. For example, the policy-server, to police resources, internal or external to the Kubernetes cluster via the "raw policies" feature.

System integrators can choose to deploy the kubewarden-controller or manage the CRDs on their own. They can choose to deploy or scale the Audit Scanner as needed.

System integrators can create new components. For example, an image scanner, and interface with it via a context-aware policy, without having a monolithic implementation in a Kubernetes controller.

Non-goals

SUSE Admission Policy Manager doesn’t intend to:

  • Replace Kubernetes built-in security features, but complement them:

  • SUSE Admission Policy Manager provides migration from PSPs.

  • You can re-use ValidatingAdmissionPolicies and CEL policies with SUSE Admission Policy Manager’s cel-policy.

  • SUSE Admission Policy Manager policies can be mutating, while Pod Security Admission cannot.

  • SUSE Admission Policy Manager policies benefit from the SUSE Admission Policy Manager stack features (audit scanner, telemetry, CRD management).

  • Provide runtime security like intrusion detection or runtime container isolation.

  • Provide host system protection of clusters.

  • Provide infinite policy execution flexibility. To prevent DoS attacks, policies' processing times are limited.

OSZAR »