ADR-028, from docs/DECISIONS.md in the QuantyKube repository.
Status In force
kubectl quanty reached the History service over the store's Unix
socket, so it had to run on the machine of the store, as root. On stage
the cluster is driven from a Windows laptop that holds a kubeconfig and
nothing else, and at a company nobody gets a shell on the control plane
to bring back a ConfigMap.
The store registers an aggregated API with the API server, an
APIService under its own group, and serves history, reads at a revision
and restores over HTTPS. The API server authenticates the caller,
authorizes with RBAC against that group, and forwards the request with
the caller's identity, which the store checks against the API server's
client certificate. kubectl-quanty becomes a thin program that calls
kubectl get --raw and kubectl create --raw, so it needs no TLS and
no kubeconfig parsing of its own, and it is built for Windows in CI.
The Unix socket keeps History for the node itself and for tests.
Rejected: a TCP endpoint of the store with client certificates for the plugin, since every user would need a certificate from the store and none of the cluster's access control would apply; and SSH to the control plane, for the reason above.
The cost: the store becomes an HTTPS server on the cluster network that the API server must reach, and a restore is now something RBAC can grant, so the default roles must not grant it.
Built on 21 October as described in docs/HISTORY.md: the History
service's own protobuf messages over HTTP/1.1, which the store offers
by ALPN so that kube-apiserver does not ask for HTTP/2; reads as get
on logs and objects, a restore as create on restores. In CI an
unmodified kube-apiserver forwards to it, kubectl-quanty lists a
ConfigMap's history and brings it back, and a user without a role is
refused.