feat: add DiscoveryContextPolicy CRD for operator-configurable discovery context rules#602
Merged
Merged
Conversation
…context source Introduces the DiscoveryContextPolicy cluster-scoped CRD (discovery.miloapis.com/v1alpha1) as a third source for the discovery context registry, taking precedence over both CRD annotations and static registrations. Supports exact GroupResource matching, wildcard group/resource patterns, and multi-policy conflict resolution via alphabetical policy name ordering. Includes a dynamic informer with retry backoff (CRD may not exist at startup), scheme registration, RBAC, a protected-resource default policy for core Kubernetes resources, and full unit + e2e test coverage. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add enum validation to Contexts field (Platform|Organization|Project|User) - Replace bounded ExponentialBackoff (10 attempts) with PollUntilContextCancel so a slow CRD bootstrap never permanently disables the policy informer - Add TestDeletePolicyRemovesWildcardEntries to cover policyWildcards cleanup - Add TestExactMatchConflictBetweenPolicies to cover alphabetical-winner logic - Regenerate CRD YAML to pick up enum constraints and remove stale RBAC rules (controller-manager does not need discovery RBAC; apiserver uses loopback) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
📝 Documentation AnalysisJoggr found 1 outdated docs in the pull request. AutofixJoggr failed to autofix the outdated docs, please try again later or contact support. Outdated
|
Remove activity from the base config/services component. The ActivityPolicy CRDs live in the activity service, which is not deployed in the milo test cluster (or any environment that hasn't installed that service). Environments that do have the activity service can include config/services/activity/ directly in their overlay. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…entity - Add Platform parent-context annotation to the namespaced Note type - Register sessions and useridentities statically in the discovery registry under the User context, since they are built-in API server resources and cannot use the kubebuilder annotation approach Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
kevwilliams
approved these changes
May 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DiscoveryContextPolicy, a new cluster-scoped CRD (discovery.miloapis.com/v1alpha1) that gives operators a Kubernetes-native way to control which parent contexts (Platform, Organization, Project, User) each API resource appears in during discoveryDiscoveryContextPolicy> CRD annotation > static registration"*"wildcards for group and/or resource, with alphabetical-first-policy-name as tiebreaker for conflictsDiscoveryContextPolicy(core-kubernetes-resources) that maps core k8s groups ("",apps,batch,networking.k8s.io,rbac.authorization.k8s.io) to Project contextMotivation
The existing contextual discovery feature only sourced context rules from CRD annotations and static registrations at startup. This left two gaps:
DiscoveryContextPolicyfills both gaps: any operator or aggregated-server author can deploy a policy object without changing Milo's source code.Implementation notes
DiscoveryContextPolicyobjects via a dynamic informer using the loopback client config (bypasses RBAC; system-level access)PollUntilContextCancelto retry indefinitely until theDiscoveryContextPolicyCRD is available — necessary because the CRD is bootstrapped by Milo's own post-start hook and may not exist when the informer hook firesHasSynced()now gates on both the CRD informer and the policy informer having completed their initial list, so the discovery filter continues to fall open during startupTest plan
go test ./pkg/server/discovery/...(13 tests: policy precedence, wildcard matching, exact-beats-wildcard, multi-policy conflict, delete cleanup,HasSyncedgating)task test:end-to-end— extendedtest/discovery-context-filter/chainsaw-test.yamlwith policy apply/verify/delete/revert stepsspec.rules[].contextstask generate:codeis idempotent (no unexpected changes)🤖 Generated with Claude Code