CLI Configuration File (AICRConfig)
CLI Configuration File (AICRConfig)
AICRConfig is a Kubernetes-style YAML/JSON document that captures the inputs
to the five workflow commands — aicr snapshot, aicr recipe, aicr bundle,
aicr validate, and aicr verify — so an end-to-end run version-controls as a
single file instead of a shell script full of flags. Each command accepts it
through the same --config flag:
The first four are the producer pipeline; spec.verify is the consumer side, so
one document can carry both how an artifact is built and the trust floor a
downstream consumer enforces against it.
This page documents the complete document schema in one place. The
CLI Reference shows per-command usage in its
Snapshot,
Recipe,
Validate,
Bundle, and
Verify config-file-mode sections.
The schema’s source of truth is
pkg/config.
Document Envelope
Each spec.* section is optional and each command reads only its own section,
so a file may carry just one section or any combination. A document with none
of the five sections is rejected.
Loading, Precedence, and Secrets
Sources. --config accepts a local file path or an HTTP/HTTPS URL
(format detected from the extension; fetches are timeout- and size-bounded).
ConfigMap cm:// URIs are intentionally rejected — extract the data with
kubectl and pass the resulting file.
Precedence. A CLI flag always wins over the matching config field. For
slice and map fields (tolerations, selectors, --set), a flag given on the
command line replaces the file’s value; it does not append.
Nil vs. empty. For agent selectors and tolerations, omitting the field
entirely (nil) inherits the compiled-in defaults (tolerations defaults to
tolerate all taints), while an explicit empty value ({} / []) clears the
default. Several booleans are tri-state for the same reason: absent means
“inherit the CLI default”, an explicit false is an opt-out
(spec.validate.execution.failOnError, failFast,
spec.snapshot.execution.privileged, spec.recipe.criteriaStrict,
spec.validate.evidence.*).
Secrets are never part of the schema. The cosign OIDC identity token used
by attestation and evidence push is deliberately absent — supply it via the
COSIGN_IDENTITY_TOKEN environment variable or the --identity-token flag.
Complete Example
Field Reference
spec.snapshot
Inputs to aicr snapshot. There is no input section — the snapshot is
produced from the live cluster.
spec.recipe
Inputs to aicr recipe. criteria and input.snapshot are mutually
exclusive — query by criteria or derive from a snapshot, not both.
spec.bundle
Inputs to aicr bundle.
When output.imageRefs is set, AICR writes the published OCI digest through a
mode-0600 temporary file and an anchored same-directory rename. The target
may be absent or an existing retained regular file; directories, symlinks,
other non-regular files, and bundle aliases are rejected. The final validation
and rename are ordered but are not one atomic identity-conditioned filesystem
operation, so no other process should mutate the target directory while the
bundle command runs.
spec.validate
Inputs to aicr validate.
spec.verify
Verification policy for aicr verify, the one consumer-side section. The two
sub-sections mirror how the command consumes them: policy holds assertions
checked after verification runs, trust holds the material it verifies against.
policy.minTrustLevel sets operator policy, not an org-enforced guardrail.
A committed value lowers the effective floor as readily as it raises it
(unknown makes the trust check a no-op, since every level meets it), so treat
it as a reviewable choice rather than a control that cannot be relaxed.
A lowered floor admits any bundle whose actual trust level reaches it, which is
broader than unsigned bundles. It also covers chains that legitimately degraded:
an attested bundle whose binary attestation is absent, or one carrying external
--data, both report attested against a verified maximum, so the default
max rejects them while a lowered floor does not.
What no policy value can wave through: checksum failures, and attestations that are present but fail verification. Those are rejected regardless of the floor.
aicr verify logs the floor at INFO when config is what supplies it: that is,
when --min-trust-level is absent and the configured value is anything other
than max. An explicit flag takes precedence instead, and that override is
logged separately by the flag-precedence path.
Every field is a durable, non-secret reference or policy value; no private key
material is part of the schema. Three aicr verify flags are deliberately
excluded: the bundle directory (a positional argument), --format
(presentation, not policy), and --insecure-ignore-tlog, which weakens the
trust floor and so stays command-line-only rather than something a committed
file can silently enable. It still composes with a config-supplied trust.key.
Cross-Section Rules
- At least one of the five
spec.*sections must be present. spec.recipe.criteriaandspec.recipe.input.snapshotare mutually exclusive.- When both
spec.recipe.output.pathandspec.bundle.input.recipeare set, they must reference the same file (compared afterfilepath.Clean; mixing absolute and relative forms is rejected). Mismatched paths in a workflow file are almost always a typo, so the loader fails up-front. - Enum-valued fields (
criteria.*, output formats, phases) are validated with the same parsers the CLI flags use, so error messages match the CLI’s.
See Also
- CLI Reference — per-command flags and config-file-mode examples
- Validation — validation phases and evidence workflow
- Bundling — deployers and bundle outputs