SeccompProfile

SeccompProfile is a namespaced kguardian CRD that describes one seccomp profile file. You own the object; the Controller on every node renders spec to standard seccomp JSON at <kubeletRoot>/seccomp/kguardian/<namespace>/<name>.json and reports per-node state in status. See the distribution guide for the workflow and policy as code for why it is shaped this way.


Group / version	`kguardian.dev/v1alpha1`
Kind / plural / short	`SeccompProfile` / `seccompprofiles` / `scmp`
Scope	Namespaced
Status subresource	yes
Installed by	the Helm chart when `seccomp.installCRDs=true` (default), or `kubectl apply -f charts/kguardian/files/kguardian.dev_seccompprofiles.yaml`
Reconciled when	`seccomp.distribute=true`

Spec

apiVersion: kguardian.dev/v1alpha1
kind: SeccompProfile
metadata:
  name: deployment-web          # becomes the file name: kguardian/<namespace>/<name>.json
  namespace: prod
spec:
  defaultAction: SCMP_ACT_LOG
  architectures: [SCMP_ARCH_X86_64, SCMP_ARCH_AARCH64]
  syscalls:
    - names: [accept4, read, write]
      action: SCMP_ACT_ALLOW
  workloadRef:
    kind: Deployment
    name: web

Field	Type	Required	Notes
`defaultAction`	enum	yes	`SCMP_ACT_LOG`, `SCMP_ACT_ERRNO`, `SCMP_ACT_KILL`, `SCMP_ACT_KILL_PROCESS`. Applied to any syscall not matched below. Exports use `SCMP_ACT_LOG`.
`architectures`	list of enum	no	`SCMP_ARCH_X86_64`, `SCMP_ARCH_AARCH64`, `SCMP_ARCH_X86`, `SCMP_ARCH_X32`. Omitted ⇒ the rendered file has no `architectures` field and the runtime uses the native one. `SCMP_ARCH_ARM64` is accepted for compatibility with older exports and is rendered on the node as `SCMP_ARCH_AARCH64`, the OCI name; new exports write `SCMP_ARCH_AARCH64`.
`syscalls`	list, min 1	yes	Each entry is `{ names, action, errnoRet? }`.
`syscalls[].names`	list of string	yes	`^[a-z][a-z0-9_]{0,63}$` each.
`syscalls[].action`	enum	yes	`SCMP_ACT_ALLOW` plus the four `defaultAction` values. kguardian only generates `SCMP_ACT_ALLOW`; the rest are for hand edits.
`syscalls[].errnoRet`	integer	no	errno returned for `SCMP_ACT_ERRNO` entries.
`workloadRef`	object	no	`{ kind, name }` in the CR’s namespace. `kind` is one of `Deployment`, `StatefulSet`, `DaemonSet`, `CronJob`, `Job`, `ReplicaSet`, `ReplicationController`. Enables the `CaptureComplete`, `Drift` and `DenialsObserved` conditions and the UI’s drift view. Distribution works without it.

The rendered node file is exactly { defaultAction, architectures?, syscalls[] } from spec, serialised deterministically. Nothing observed by kguardian is mixed in — what is on disk is what is in git.

Status

Written by the controllers only; you never set it.

status:
  observedGeneration: 3
  hash: "a1b2c3d4e5f60718"
  localhostProfile: kguardian/prod/deployment-web.json
  distribution: { ready: 12, total: 12, state: Ready, summary: "12/12" }
  drift: "False"
  denials:
    observed: 17
    actions: [SCMP_ACT_LOG]
    syscalls: [mount, ptrace]
    lastSeen: "2026-09-14T04:05:14Z"
    refreshedAt: "2026-09-14T04:05:30Z"
  nodes:
    - name: node-a
      hash: "a1b2c3d4e5f60718"
      lastWritten: "2026-09-03T01:00:00Z"
  conditions:
    - type: Ready
      status: "True"
      reason: AllNodes
      message: "12/12 nodes"
    - type: CaptureComplete
      status: "True"
      reason: Full
      message: "full capture on 2 pod(s)"
    - type: Drift
      status: "False"
      reason: InSync
      message: "every observed syscall is in spec"
    - type: DenialsObserved
      status: "True"
      reason: KernelDenied
      message: "17 seccomp denial(s) (SCMP_ACT_LOG) on 2 syscall(s): mount, ptrace; last seen 2026-09-14T04:05:14Z"

Field	Meaning
`observedGeneration`	The `metadata.generation` the summary was computed for.
`hash`	FNV-1a-64 of the rendered file bytes — what a node should have on disk.
`localhostProfile`	The value to put in `securityContext.seccompProfile.localhostProfile`.
`distribution`	`ready` live nodes whose entry in `nodes` carries the current `hash`, out of `total` live nodes; `state` is `Ready` (`ready == total > 0`), `Partial`, or `Pending` (`ready == 0`). `summary` is the `ready/total` string the printer column shows.
`drift`	Mirror of the `Drift` condition’s status (`True`/`False`/`Unknown`) for the printer column — printer columns take simple JSON paths, not condition filters.
`denials`	Present whenever the Broker has an answer for `workloadRef`’s workload, including when that answer is zero. `observed` is the total across every syscall and action — it is the `DENIALS` printer column; `actions` is the distinct verdicts the kernel returned (`SCMP_ACT_LOG` in audit mode; an enforcing action after promotion), sorted; `syscalls` is the distinct names, sorted; `lastSeen` is the most recent denial and `refreshedAt` the last time the controller re-read the answer from the Broker, both RFC 3339. `observed: 0` means checked and clean; the block being absent means not known.
`nodes[]`	One entry per node, keyed by `name` (`x-kubernetes-list-type: map`). Each controller server-side-applies only its own entry, with field manager `kguardian-controller/<node>`. Entries for nodes that have left the cluster are removed on the next pass, so the list tracks the nodes the cluster has, not every node it has ever had.
`conditions[]`	Standard `metav1.Condition` list, below.

Conditions

Type	Status	Reason	When
`Ready`	`True`	`AllNodes`	every live node has the current hash
	`False`	`SomeNodes` / `NoNodes`	message carries `ready/total`
`CaptureComplete`	`True`	`Full`	every pod that contributed syscalls for `workloadRef` was captured at the `full` tier
	`False`	`PartialCapture`	message names the lowest tier and the pods
	`Unknown`	`NoWorkloadRef` / `NoObservations`	no `workloadRef`, or nothing observed yet
`Drift`	`True`	`ObservedNotInSpec`	the workload made syscalls not allowed by `spec`; message lists them
	`False`	`InSync`
	`Unknown`	`NoWorkloadRef` / `NoObservations`	no `workloadRef`, or the Broker has no observations for the workload
`DenialsObserved`	`True`	`KernelDenied`	a loaded filter acted on at least one syscall for this workload inside the retention window; `status.denials` carries the count, the syscalls, and `lastSeen`
	`False`	`NoDenials`	the Broker looked and found none. `status.denials` is `{observed: 0}`
	`Unknown`	`NoWorkloadRef` / `NoObservations` / `NoDenialData`	no `workloadRef`; nothing observed for the workload; or the Broker sent no `denials` block at all — it predates denial capture, or nothing in the cluster is capturing denials

The summary (distribution, Ready) is computed by every controller from the CR’s own nodes list plus a live node count and applied with field manager kguardian-summary; every node computes the same value, so last-writer-wins converges. CaptureComplete, Drift and DenialsObserved come from the Broker and are applied the same way. Controllers only patch when a value changes. When the Broker cannot be reached at all, those three conditions and status.denials are left exactly as they were rather than flapping to Unknown — an outage is not an answer, and the CR should not start contradicting what it last knew because a scrape failed. On a CR that has never had a successful pass there is nothing to carry forward, so the three are absent from conditions entirely rather than present as Unknown. Anything selecting a condition by type has to handle it not being there.

observed: 0 and an absent denials block are opposite answers, and the difference is what gates promotion. 0 means kguardian checked and this workload’s profile has never fired. Absent means nobody checked — the Broker was unreachable, predates denial capture, or nothing in the cluster is capturing denials. Promoting a profile to an enforcing action on an absent block is promoting on no evidence at all.The rule to automate against: status.denials is present exactly when DenialsObserved is True or False, and absent exactly when it is Unknown. The block and the condition are two readings of one answer and never disagree, so gate on whichever is convenient — .status.denials.observed == 0 and DenialsObserved == False mean the same thing.

Denials are a different signal from Drift, which is inferred from observed syscalls rather than from the kernel’s verdict — see Denials vs Drift.

Printer columns

$ kubectl -n prod get seccompprofiles
NAME             ACTION           READY   DRIFT   DENIALS   AGE
deployment-web   SCMP_ACT_ERRNO   12/12   False   17        3d
media-transform  SCMP_ACT_LOG     12/12   False   0         2d
batch-indexer    SCMP_ACT_LOG     12/12   True              5h

ACTION is spec.defaultAction, READY is status.distribution.summary, DRIFT is status.drift, DENIALS is status.denials.observed. The three DENIALS cells above are three different answers, readable without leaving the table. 17 — the kernel is acting on this profile. 0 — checked, and it has never fired, so media-transform is the one clear to promote. Blank — nothing is known, and batch-indexer is not a promotion candidate however good the rest of its row looks. A blank is never a quiet 0.

Delete semantics

Deleting a SeccompProfile deletes the file from every node on the next watch event. This is the only time kguardian removes anything from a node, and it follows your explicit deletion. A pod that still references the path fails its next start with CreateContainerError — remove the seccompProfile reference from the workload first, roll it, then delete the CR. Uninstalling the chart does not delete the CRD when seccomp.installCRDs is on: it is annotated helm.sh/resource-policy: keep, because dropping a CRD deletes every object of that kind with it. This CRD is rendered as a chart template rather than shipped in crds/ (as the older AuditNetworkPolicy CRDs are) so that helm upgrade can apply schema changes — Helm never upgrades anything under crds/. Delete it by hand (kubectl delete crd seccompprofiles.kguardian.dev) once you have removed every profile reference.

RBAC

With seccomp.distribute=true the chart grants the Controller’s ServiceAccount get/list/watch on seccompprofiles, patch on seccompprofiles/status, and list on nodes. Nothing is granted when distribution is off. Users need ordinary namespaced RBAC on seccompprofiles.kguardian.dev to create and edit profiles.

Getting Started

Core Concepts

User Guides

Policy Gallery

CLI Reference

CRD Reference

Configuration Reference

Advanced

Roadmap

Spec

Status

Conditions

Printer columns

Delete semantics

RBAC

​Spec

​Status

​Conditions

​Printer columns

​Delete semantics

​RBAC

Spec

Status

Conditions

Printer columns

Delete semantics

RBAC