The agent could only reach lab-mgmt, so it couldn't verify nodes, CNI or
system pods on lab1. It correctly refused the admin ~/.kube/lab1.kubeconfig
when the owner's permission was relayed through the main session.
Workload kubeconfigs:
- make-kubeconfig.sh: new --capi-cluster [NS/]NAME. --admin-kubeconfig
is then the management cluster. The workload admin kubeconfig is read
from Secret NS/NAME-kubeconfig into a mktemp file, removed on exit, so
no admin file for the workload cluster lands on disk.
- ansible/mgmt.yml --tags inspector now also mints kubeconfigs for every
cluster in the new inspector_workload_clusters (group_vars: lab1).
Clusters without a <name>-kubeconfig Secret are skipped. The tag is now
the single weekly token refresh; tasks stay changed_when: false, so the
playbook's changed=0 rule still holds.
- Owner ran --tags inspector: kubeconfigs/lab1.kubeconfig (lab1-ro)
minted, can-i checks as expected.
Agent prompt:
- Cluster map: what to inspect on lab-mgmt vs the workload cluster.
Machine -> Node -> VM via nodeRef, providerID and
ProxmoxMachine.spec.virtualMachineID (checked on live objects).
- New triage step: scale-down blockers (non-DaemonSet kube-system pods
without PDB, local storage, bare pods, PDBs at 0, safe-to-evict /
scale-down-disabled).
- Refuses admin kubeconfigs even when a caller relays permission; points
the owner to --tags inspector on missing file or 401.
- Verb before --kubeconfig so commands match the kubectl get/describe/logs
allow rules; single-quote jsonpath/custom-columns for zsh.
- Report format: abnormal first, then health summary, then unverified.
settings.json: allow kubectl describe/logs/events and clusterctl describe.
All four are read-only, and the RO kubeconfigs enforce read-only anyway.
Checked: bash -n on the script; ansible-playbook --syntax-check and
ansible-lint --profile production pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
stringData is never stored, so kubectl apply reported "configured" on
every run and the capi play was never changed=0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PVE's cloud-init user-data triggers a deprecation warning that makes
`cloud-init status --wait` exit 2 even though provisioning succeeded.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VM from Ubuntu cloud image on pv1-1, pinned k3s, cert-manager and
cluster-api-operator via k3s HelmChart CRs, CAPI providers as operator CRs,
kubeconfig fetch + cluster-inspector kubeconfig. Lint passes (production).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kacerrandClaude Opus 5.5