A GitOps repository collects small debts: a container with no resource requests, a pod that runs as root, a missing label, an image pull policy nobody set. None of them is urgent, all of them add up. The scanner reads every YAML file, fixes what a rule can fix, asks a model only about what needs judgement, and hands you small draft MRs that touch nothing else.
Every six hours the scanner lists the YAML files in each configured repository. A file whose content hash has not changed since the last pass is skipped, so a quiet repository costs almost nothing.
System namespaces (kube-system, flux-system,
cert-manager) and kinds such as CRDs are excluded by
default, and very large files are skipped rather than half-read.
Each manifest is run through kube-score, an in-house structural rule pack (Flux API versions, HelmRelease remediation settings, HPA target bands) and Trivy's misconfiguration checks.
A finding a rule can decide is never left to a model to rediscover. Findings already proposed and still open are recognised and not raised again.
For a fixed set of rules there is a patcher: image pull policy, read-only root filesystem, running as a non-root user, ephemeral-storage requests, rollout strategy, replicas, and new PodDisruptionBudgets or NetworkPolicies. The patch is made in memory and becomes its own proposal.
A patcher can also refuse. If a container writes to an unbounded local cache, picking an ephemeral-storage cap would get the pod evicted, so the scanner asks you for the size instead of guessing.
Only then does a model read the manifest. It sees the file after the deterministic patches, so it cannot re-propose them, plus the linter findings it should skip and, for workloads, recent CPU and memory usage from your metrics backend.
Each suggestion has to carry a category, a confidence and evidence. Low-confidence suggestions are dropped.
The model does not rewrite the file. It returns a short list of structured edits: an operation, a YAML path, a value. These are applied by a round-trip YAML editor that touches only that path.
Comments, key order, block scalars and every other document in a multi-document file stay byte-for-byte as they were. An edit that names a file outside the scan is rejected. No cosmetic churn.
Every diff is checked before it can become an MR. One that removes
more than half of a file is escalated to high risk and held as
NEEDS_REVIEW. One that looks like a truncated file is
flagged too.
If the live object behind the file is rendered by a Helm chart, editing the rendered output would fight the chart forever, so the proposal is escalated with a pointer to the HelmRelease values as the right place for the fix.
Two additive findings on the same file are merged into one diff. The same additive change across many files (standard labels, say) becomes one MR listing every file, instead of twenty.
Functional changes such as upgrades or API-version migrations are never bundled across environments, so dev, staging and production can still be merged one at a time. Rule-based patches and model suggestions stay in separate MRs.
For orders-api that means one draft MR: resource
requests sized from observed usage, and a hardened security context,
merged into one file's diff. The full MR is below.
containers: - name: orders-api image: registry.acme.example/shop/orders-api:4.12.0 + imagePullPolicy: IfNotPresent
refused: container cart mounts an unbounded emptyDir cache a fixed cap could get the pod evicted; recurring refusals become an issue asking you for the real size
[ { op: set, path: spec.template.spec.containers[orders-api].resources.requests,
value: { cpu: 200m, memory: 512Mi } } ]
- name: orders-api # pinned by the release job, do not edit by hand image: registry.acme.example/shop/orders-api:4.12.0 + resources: + requests: + cpu: 200m + memory: 512Mi env: … untouched, comments kept …
+ resources: + requests: { cpu: 200m, memory: 512Mi } + securityContext: + runAsNonRoot: true + allowPrivilegeEscalation: false + readOnlyRootFilesystem: true
Illustrative: two findings on the same file, bundled into one draft MR because both only add lines.
gitops-ai/set-resource-requests-and-harden-securitycontext-5d2e91ab into main · 1 file · +11This bundle combines two findings on apps/shop/orders-api/deployment_orders-api.yaml. Both only add lines, so they merge without conflict.
| Finding | Category | Change |
|---|---|---|
No resource requests on orders-api | resources | Requests set from observed usage |
| Container may run as root with a writable root filesystem | security | securityContext added |
Without requests the scheduler packs this pod as if it needed nothing, so it is first to be starved on a busy node. Without a security context a compromised process can write to its own image and run as UID 0.
| Metric | p95 | Peak | Proposed request |
|---|---|---|---|
| CPU | 180m | 310m | 200m |
| Memory | 395Mi | 410Mi | 512Mi |
No resources block and no securityContext on the container. The image declares a non-root user, so runAsNonRoot: true does not change who the process runs as. Writes go to the mounted /tmp volume, not the root filesystem.
No limits are proposed: limits on a latency-sensitive service are a decision for its owners.
containers:
- name: orders-api
# pinned by the release job, do not edit by hand
image: registry.acme.example/shop/orders-api:4.12.0
+ resources:
+ requests:
+ cpu: 200m
+ memory: 512Mi
+ securityContext:
+ runAsNonRoot: true
+ allowPrivilegeEscalation: false
+ readOnlyRootFilesystem: true
+ capabilities:
+ drop: ["ALL"]
+ seccompProfile: { type: RuntimeDefault }
env:
- name: LOG_LEVEL
orders-api./tmp it will fail at start, so watch the first rollout.Revert this MR.
Checked that the image runs as a non-root user and only writes to the mounted volume. Requests sit just above p95. Diff scope matches the title. LGTM.
The model proposes. Code applies the change and decides whether it may leave.