Available

Policy and compliance · for Kubernetes clusters

Score your cluster against the frameworks you answer to, and close each gap.

AuthFI reads what is running in your cluster, scores it against nine frameworks and AuthFI's AI baseline, names the rule that closes each gap, and works with the Kyverno policies you already have.

The Compliance page in the AuthFI console: a cluster scored against the CIS Kubernetes Benchmark.

A cluster, scored

One cluster against a framework's controls. Only a pass is a pass; a control that cannot be decided says why.

Nine frameworks and AuthFI's AI baseline, one scan

83 controls in the catalogue. A cluster's own objects can decide some of them; every other control is listed with the reason it cannot be decided from a cluster.

CIS Kubernetes Benchmark

v1.9

13 controls

SOC 2

Trust services criteria

3 controls

ISO/IEC 27001

2022

4 controls

NIST SP 800-207

Zero trust, all seven tenets

7 controls

PCI DSS

v4.0

12 controls

HIPAA Security Rule

45 CFR 164 subpart C

21 controls

OWASP Top 10

2021

2 controls

OWASP API Security Top 10

2023

10 controls

OWASP Top 10 for LLM

2025

10 controls

Kernel cage baseline for AI workloads

AuthFI

1 control

Five answers. Only one is a pass.

A report that shows a tick for everything it did not look at is clean by not looking. Every control gets one of five answers, and four of them are not a pass.

Pass

We looked, and found nothing wrong.

Fail

We looked, and found something. Each finding names the object and the part that failed.

Nothing of this kind

We looked, and your cluster has no objects this control applies to.

We cannot decide

Nothing in a cluster can answer this control. The row says why.

Cluster not reporting

The cluster has never reported, so there is nothing to score. Shown as a danger, not a blank.

Closing a gap

The rule that closes each gap, and what it would cost.

For a failing control AuthFI names the rule that would close it. Before you turn anything on, you see how many of your workloads it would refuse and what stops working.

Counted against your cluster as it is now, not predicted

Says what it would disrupt, in words

Arms nothing: a person decides

The Compliance page in the AuthFI console: controls with their status, objects scanned and how many workloads a rule would refuse.The Compliance page in the AuthFI console: controls with their status, objects scanned and how many workloads a rule would refuse.

Works with Kyverno

Kyverno refuses at admission. AuthFI tells you what is worth refusing, reads the policies you already run, and writes the ones you are missing.

Reads the policies you run

It does not tell you to fix what you already fixed.

  • A control already refused by one of your Kyverno policies is marked as guarded, with the policy named.
  • A policy in Audit mode is not counted as protection. It watches; it does not refuse.
  • A rule AuthFI cannot read is named as untranslated, never quietly assumed to cover you.
  • Your Kyverno rules appear on the Policy page beside every other rule in force.

Writes the ones you are missing

Copy a complete policy, ready to apply.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privilege-escalation
spec:
  validationFailureAction: Audit
  background: true
  rules:
    - name: disallow-privilege-escalation
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: Containers must not allow privilege escalation
        pattern:
          spec:
            =(containers):
              - securityContext:
                  allowPrivilegeEscalation: "false"

Exported policies are set to Audit, so nothing breaks until you choose to enforce.

Policy

Every rule in force, and whether it would refuse.

Service access, network, outbound connections, privileged commands, access decisions and your Kyverno admission policies are read together. Each rule gets one honest state.

Refuses, watching, refuses nothing, or cannot tell

Each rule links to the screen that owns it

A source that could not be read is named, not skipped

The Policy page in the AuthFI console: every rule in force and whether it would refuse.The Policy page in the AuthFI console: every rule in force and whether it would refuse.
Pilot

Posture

Standing conditions, not a stream of events.

A finding is a condition that stays open until your estate changes, such as a privileged pod or a server that permits SSH root login.

By layer: sign-in, services, infrastructure and cloud

By severity, so the worst is first

A fixed condition leaves the list

The Posture page in the AuthFI console: open findings by layer and severity.The Posture page in the AuthFI console: open findings by layer and severity.

What this is, and what it is not

Stated plainly, because a compliance score is easy to misread.

It is evidence, not a certificateWhat an auditor still does

Not an audit

A score shows how your cluster stands against a framework's technical controls. It does not certify you, and it does not replace your auditor.

Cluster controls only

Controls about your practices, such as training, incident procedures or physical access, cannot be decided from a cluster. They are listed as undecided, with the reason.

As fresh as the last sync

The score describes what the cluster last reported. If that is more than an hour old, the page says so.

Kyverno does the refusing

These rules decide whether an object may exist. They are enforced at admission by Kyverno, which you run. AuthFI's own enforcement is on connections and sign-in.

Where each part standsFive available, one in pilot, one in development

Cluster scored against nine frameworks and AuthFI's AI baseline

Available

The rule that closes each gap, counted against your cluster

Available

Export as Kyverno policies

Available

Recognises the Kyverno policies you already run

Available

Every rule in force, and whether it would refuse

Available

Standing posture findings

Pilot

Reports for auditors, as a document

In development

See how your cluster scores.