Goldilocks exposes resource recommendations and capacity data

Goldilocks uses Kubernetes Vertical Pod Autoscaler recommendations to show how much CPU and memory a workload may need. The dashboard helps teams right-size requests and limits. It also reveals workload names, namespaces, container usage patterns, and the difference between requested and recommended resources. A public Goldilocks page can therefore disclose operational and capacity information.

The observed counts

On 2026-11-11 at 23:49 UTC, a count-only ZoomEye query used sub_type=all, page 1, and page size 1. title="Goldilocks" returned 323 matches. The same probe returned 1 for app="Goldilocks" and 4,270 for http.body="Goldilocks".

The application count is very small, which makes it useful as a specific clue but weak as a population estimate. The title count is broader and may include unrelated uses of the fairy-tale name. The body count is useful only for discovery. A product page should be confirmed against Fairwinds documentation and the asset owner before it is classified as Goldilocks.

What the dashboard contains

Fairwinds documentation describes a dashboard and a controller. The controller creates VPA objects for workloads in selected namespaces, and the dashboard shows recommendations. The recommendation data can reveal which services are oversized, which are underprovisioned, and when workloads change.

That information can support an attacker who is mapping production services or looking for resource pressure. It can also reveal business activity through namespace and workload names. Resource recommendations are not secrets in the credential sense, but they are internal operational data.

Access and deployment

The documentation shows dashboard access through port forwarding in common installations. A port-forward keeps the service on the Kubernetes network and requires cluster credentials. If a team exposes the dashboard through an ingress, it should add authentication, network policy, and a clear owner. Do not assume that a dashboard with no write action is safe to publish.

Review the VPA recommender and updater permissions. A Goldilocks controller creates or manages VPA resources in the namespaces it watches. Restrict the watch scope and the service account permissions. If the controller can modify workloads directly, that is a different risk from a read-only recommendation dashboard.

Validation and monitoring

List namespaces selected by Goldilocks labels. Confirm that the controller does not watch sensitive namespaces without an owner's approval. Review VPA objects for unexpected update modes. Check the dashboard ingress and authentication path. Preserve audit logs for access to recommendations and for changes to the controller configuration.

The dashboard should fail closed if authentication is unavailable. A temporary ingress change that removes the proxy should not turn the dashboard into a public service. Add a synthetic check that requests the public URL without credentials and expects a denial.

From a name to an asset

Use the 323 title matches as a lead. Verify each candidate through ownership records and product-specific content. Do not treat a fairy-tale page as a Kubernetes dashboard. For confirmed assets, compare the observed URL with the approved ingress inventory and the cluster's namespace scope.

Goldilocks is a small product with a narrow purpose, which makes it a good example of why product-specific context matters. The useful measurement is not how many pages use the name. It is how many owned dashboards expose workload resource data outside the intended network and identity boundary.