feat: Introduce SearchQuery API and Refine Indexing Infrastructure

[JoseSzycho]

Pull Request: Introduce SearchQuery API and Refine Indexing Infrastructure

Description

This PR introduces the SearchQuery API, enabling full-text search capabilities against Meilisearch through the Kubernetes aggregated API server. It also includes several refinements to the indexing infrastructure, RBAC, and logging.

Key Features

1. SearchQuery API Implementation

• New SearchQuery Resource: Added the SearchQuery virtual resource in pkg/apis/search/v1alpha1.
• REST Storage: Implemented the REST storage for SearchQuery in internal/registry/searchquery/rest.go, handling:
  • Integration with Meilisearch MultiSearch API.
  • Robust JWT-based pagination using continue tokens that validate against the original search parameters.
  • Centralized management of the JWT signing secret in the main application entry point.
• API Server Integration: Updated the aggregated API server to register the searchqueries endpoint.

Fixes

1. Indexer and Cache Refinements

• Centralized Cache Sync: Refactored the PolicyCache to use a centralized startup and synchronization mechanism based on controller-runtime.

2. Infrastructure and Tools

• RBAC Enhancements: Added comprehensive RBAC rules for the resource-indexer, including cluster-wide permissions to get/list/watch resources.

Note

Commit 52f2517 contains the actual new feature

[scotwells]

Getting some early feedback in! Will try and take a look at the Resource embed thing shortly.

[scotwells]

We should use structured errors with field errors so that all errors are returned to the client instead of only validating part of the error.

[scotwells]

Let's use the name ResourceSearchQuery so it's a little more unique to what we're searching. This gives us flexibility to have other types of search queries in the future that won't conflict with this type.

[scotwells]

We'll want to investigate if there's a better way to embed a resource here. I believe this would result in a raw JSON object which is not ideal.

[scotwells]

After investigation, unstructured.Unstructured is the better choice here over runtime.RawExtension.

Why Unstructured:

• Provides typed accessor methods for Go clients (GetName(), GetNamespace(), GetLabels(), etc.) without requiring manual JSON parsing
• Implements runtime.Object, so it works directly with dynamic clients and controller-runtime machinery
• Wire format is identical to RawExtension—non-Go clients see the same JSON, so this is backward compatible

Why not RawExtension:

• Clients must manually unmarshal and type-assert fields
• No benefit over Unstructured since we are not doing raw byte pass-through

Alternative considered:
We could extract common fields (apiVersion, kind, name, namespace) into explicit struct fields for maximum ergonomics, but Unstructured provides a good balance without duplicating data in the response.

type SearchResult struct {
    Resource       unstructured.Unstructured `json:"resource"`
    RelevanceScore float64                   `json:"relevanceScore,omitempty"`
}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}