Manifests and live objects, side by side#
Proofline reads the manifests at the exact commit under review. It also lists live objects from your cluster: pods, deployments, stateful sets, daemon sets, jobs, services, ingresses, network policies, autoscalers, and disruption budgets.
The evidence keeps declared and live objects apart, so a finding can show what the manifest says, what the cluster reports, and where they disagree.
A new call that a network policy blocks#
Suppose, for illustration, that a pull request makes the checkout service call a new endpoint on the ledger service. It works in a test cluster that has no network policies.
In production, a network policy in the ledger namespace admits traffic only from the billing namespace. After the deploy, requests from checkout would time out.
The finding cites the new call in the diff and the live policy, and suggests shipping a policy change with the code.
Read-only access to the cluster#
Proofline connects to any Kubernetes cluster, on EKS, GKE, or your own servers, through a read-only service account. The account has get and list permissions on the resource types above, in the namespaces you choose.
GKE clusters connect through your Google Cloud connection.
The service account does not watch, change, or exec into anything, and it does not read custom resources. If Proofline cannot reach the cluster, it reports the review as incomplete and says why.
Questions#
Which Kubernetes clusters does Proofline support?
Proofline supports any Kubernetes cluster, including EKS, GKE, and self-managed clusters. It reads each one through a read-only service account with get and list permissions. GKE clusters connect through your Google Cloud connection.
Does Proofline read Kubernetes secrets?
No. The resource types Proofline lists exclude secrets and config maps.
Can Proofline change my cluster?
No. Proofline's service account has only get and list permissions, in the namespaces you choose.