Add accesspolicy controller - #1257
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
62298b1 to
d529995
Compare
Signed-off-by: vibhor kumar <vibhork1105@gmail.com>
d529995 to
a541de3
Compare
| SectionName *string `json:"sectionName,omitempty"` | ||
| } | ||
|
|
||
| type AccessPolicySpec struct { |
There was a problem hiding this comment.
We should probably not redefine the type in our codebase but import it from sigs.k8s.io/kube-agentic-networking.
Rebuilding the CRD from code ourselves is unexpected, as we don't own the API group, and risks becoming inconsistent with the source of the upstream. Instead, we should make having the CRD installed a requirement for using the controller.
| return ctrl.Result{}, nil | ||
| } | ||
|
|
||
| targetRef := policy.Spec.TargetRefs[0] |
There was a problem hiding this comment.
An XAccessPolicy resource could still target multiple different gateways, no? Are planning to support multiple targets?
| // Fetch all XAccessPolicies targeting this gateway | ||
| var policyList agenticv1alpha1.XAccessPolicyList | ||
| if err := r.List(ctx, &policyList, client.InNamespace(policy.Namespace)); err != nil { | ||
| return ctrl.Result{}, err | ||
| } |
There was a problem hiding this comment.
Because what we'll be actually reconciling is the state of the gateways, not the policies, there's a different pattern that could be used here. Instead of implementing a reconciler for XAccessPolicy custom resources, we can implement a Gateway reconciler instead – although the name doesn't really matter. The important part is that, with this pattern, the object that the reconciler receives in the request argument is of the Gateway kind, not of the XAccessPolicy kind. We then define an event mapping function/handler that perceives XAccessPolicy-related events but enqueues calls to reconcile each of the Gateway objects referenced in the spec.targetRefs of the policy instead.
This could save from having to list all gateways for each individual policy reconciliation and, within the loop, all policies affected by the gateway, while multiple reconciliation events related to multiple XAccessPolicy resources may be enqueue – effectively to yield the same outcome but with more cycles.
See controller-runtime's EnqueueRequestsFromMapFunc.
| if rule.Source.Type == agenticv1alpha1.AuthorizationSourceTypeSPIFFE { | ||
| continue |
There was a problem hiding this comment.
I'll have to think this through, but I think there may be something we can do regarding authentication here.
I'm thinking maybe using the plain type of authentication from the AuthPolicy when an SPIFFE ID is known to be injected by the proxy, say, for example, because it has mTLS authentication enabled.
2 participants
Description
This PR introduces the XAccessPolicy Controller, a Kubernetes controller designed to bridge the gap between high-level, gateway-agnostic MCP authorization intent and the concrete enforcement mechanisms provided by Kuadrant's Authorino.
It watches
XAccessPolicyresources targetingGatewayobjects and enables declarative, tool-level access control for MCP (Model Context Protocol) servers.Key Responsibilities:
request.mcp.tool_name) into their data-plane equivalents (e.g.,request.headers['x-mcp-toolname']) that Authorino can evaluate at runtime.XAccessPolicyrules targeting the same Gateway into a single KuadrantAuthPolicy, seamlessly handling Kuadrant's 1:1 policy-to-target constraint.Relates to #804