Add CI

ci/README.md

@@ -0,0 +1,58 @@
+# 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 the local cluster, runs the job, stores the JSON report,
+and prints pass, warn, and fail totals in the workflow summary. 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.
+