# CIS benchmark scanning

The scan uses the official kube-bench K3s profile, `k3s-cis-1.7`, against a
disposable K3d control-plane node. kube-bench needs host PID access and
read-only host mounts because the CIS checks inspect processes, permissions,
and node configuration. The job is intentionally separate from the ArgoCD
application tree so the scanner cannot become part of the workload baseline.

GitHub Actions creates a disposable one-server K3s cluster, runs the job,
stores the JSON report, and prints pass, warn, and fail totals in the workflow
summary. The CI topology is intentionally smaller than the developer
quick-start topology so it remains reliable on shared runners.

The workflow
fails if the scanner job or report generation fails. It does not yet fail on
CIS findings because a vanilla K3d cluster is expected to produce findings;
later hardening phases can turn selected controls into merge gates.

To run the same scan locally against the active K3d cluster:

```bash
kubectl create namespace kube-bench --dry-run=client -o yaml | kubectl apply -f -
kubectl delete job kube-bench -n kube-bench --ignore-not-found
kubectl apply -f ci/kube-bench-k3s-job.yaml
kubectl wait --for=condition=complete job/kube-bench -n kube-bench --timeout=180s
kubectl logs -n kube-bench job/kube-bench > kube-bench-report.json
```

The benchmark release is pinned in the Job image. Update it deliberately when
the benchmark support matrix or K3s version changes.

## Gitea Actions support

Gitea Actions can run the same workflow file. Gitea's default workflow search
order includes `.gitea/workflows` and `.github/workflows`; because this
repository has no `.gitea/workflows` directory, Gitea will discover the
existing `.github/workflows/kube-bench-scan.yml` file. GitHub Actions continues
to use that same file.

The Gitea instance must have Actions enabled and an `act_runner` registered at
the repository, organization, or instance level. The runner needs Docker
access because the workflow creates a k3d cluster and runs the kube-bench Job.
Register a dedicated runner for this repository rather than sharing a runner
with unrelated repositories.

Example Docker runner setup, with the registration token supplied separately:

```bash
docker run -d \
  --name kubernetes-security-baseline-runner \
  -e GITEA_INSTANCE_URL=https://git.swaphb.com/ \
  -e GITEA_RUNNER_REGISTRATION_TOKEN="$GITEA_RUNNER_REGISTRATION_TOKEN" \
  -e GITEA_RUNNER_NAME=kubernetes-security-baseline \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v gitea-runner-data:/data \
  docker.io/gitea/act_runner:latest
```

Mounting the Docker socket gives workflow jobs substantial control over the
runner host. Use a dedicated disposable runner, restrict its repository scope,
and avoid placing unrelated credentials on that host.