Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -111,9 +111,12 @@ BOILERPLATE_FILE := hack/boilerplate/boilerplate.generatego.txt
.PHONY: generate
generate: manifests deepcopy register clientsets ## Generate manifests, deepcopy code, and clientsets.

# TODO: Remove the python post-processing patch once XAccessPolicy v1alpha1 is fully implemented
# and flipped to `served: true` instead of v0alpha0.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we have a tracking issue for this?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Planning to fast follow after I add ref implementation support for the new field structure (i.e moving the support to support the v1alpha1 from v0alpha0)

.PHONY: manifests
manifests: controller-gen ## Generate CustomResourceDefinition objects.
$(CONTROLLER_GEN) rbac:roleName=manager-role crd paths="./api/..." output:crd:artifacts:config=k8s/crds
python3 -c "p='k8s/crds/agentic.networking.x-k8s.io_xaccesspolicies.yaml'; text=open(p).read(); parts=text.split(' - name: v1alpha1'); parts[1]=parts[1].replace(' served: true', ' served: false', 1); open(p,'w').write(' - name: v1alpha1'.join(parts))"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should put this in a hack/script.py. (follow up PR)


.PHONY: deepcopy
deepcopy: controller-gen ## Generate code containing DeepCopy, DeepCopyInto, and DeepCopyObject method implementations.
Expand All @@ -133,14 +136,20 @@ clientsets: ## Generate clientsets, listers, and informers.
./'

.PHONY: register
register: ## Generate register code for CRDs under ./api/v0alpha0
register: ## Generate register code for CRDs under ./api/v0alpha0 and ./api/v1alpha1
@echo "--- Ensuring code-generator is in module cache..."
@go mod download k8s.io/code-generator
@echo "+++ Generating register code for api/v0alpha0..."
@bash -c 'source $(CODEGEN_SCRIPT); \
kube::codegen::gen_register \
--boilerplate $(BOILERPLATE_FILE) \
./api/v0alpha0'
@echo "+++ Generating register code for api/v1alpha1..."
@bash -c 'source $(CODEGEN_SCRIPT); \
kube::codegen::gen_register \
--boilerplate $(BOILERPLATE_FILE) \
./api/v1alpha1'


## @ Dependencies

Expand Down
1 change: 1 addition & 0 deletions api/v0alpha0/accesspolicy_types.go
Original file line number Diff line number Diff line change
Expand Up @@ -205,6 +205,7 @@ type AccessPolicyStatus struct {
// +genclient
// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:storageversion

// XAccessPolicy is the Schema for the accesspolicies API.
type XAccessPolicy struct {
Expand Down
302 changes: 302 additions & 0 deletions api/v1alpha1/accesspolicy_types.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,302 @@
/*
Copyright The Kubernetes Authors.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

// IMPORTANT: Run "make generate" to regenerate code after modifying this file

package v1alpha1

import (
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

gwapiv1 "sigs.k8s.io/gateway-api/apis/v1"
)

// AccessPolicySpec defines the desired state of AccessPolicy.
//
// Implementations SHOULD return a regular HTTP formatted response if the policy is enforced against non-MCP traffic.
// Implementations MAY return a JSON-RPC formatted response if the policy is enforced against MCP traffic.
// +kubebuilder:validation:XValidation:rule="self.action == 'ExternalAuth' ? has(self.externalAuth) : true",message="externalAuth must be specified when action is set to 'ExternalAuth'"
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit confused. When the AccessPolicyActionType is ExternalAuth, does the external server do both the authentication and autherization? If so, does it mean that the AccessRule field is not needed in that case?

Also, how does the external server do Authentication? What identity does the controller use to talk to the external auth sever?

type AccessPolicySpec struct {
// TargetRefs specifies the targets of the AccessPolicy.
// An AccessPolicy must target at least one resource.
// There is one kind of TargetRef with "Core" support:
//
// * Gateway
//
// This API may be extended in the future to support additional kinds of targetRefs.
// Implementations may support additional kinds in an implementation specific manner.
// +required
// +kubebuilder:validation:MinItems=1
// +kubebuilder:validation:MaxItems=10
// +listType=atomic
// +kubebuilder:validation:XValidation:rule="self.all(ref, ref.kind == self[0].kind)",message="All targetRefs must have the same Kind"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why

// +kubebuilder:validation:XValidation:rule="self.all(x, (x.group == 'agentic.networking.x-k8s.io' && x.kind == 'XBackend') || (x.group == 'gateway.networking.k8s.io' && x.kind == 'Gateway'))",message="TargetRef must have group agentic.networking.x-k8s.io and kind XBackend, or group gateway.networking.k8s.io and kind Gateway"
is not included in this PR?

If we decide to keep supporting Backend-targeted AccessPolicy in the reference implementation, we should allow the target to be either Gatway or Backend.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think given there is no official support for XBackend, we should leave references to it out of the validation. When the support is official, then it makes sense to add it back in.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Haiyan, as we indicated before, the release is not going to include XBackend in it. Therefore Core support for targeting AccessPolicy is going to be only Gateway. However, we still want to allow room for extensibility for targeting any GVK (one example would be the protoype in this repo which will continue to target v0alpha0 backend) so can not have this validation.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we validate the targetRef in control plane?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TargetRef validation would be in each control plane, yes. And if invalid status will be posted.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is about not mixing targetRefs?
So all can be Gateways, or all can be XBackends, but not a mix of both?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. To start simple. I think this came out of a conclusion in extAuth discussion where Backend and Gateway could have been confusing to be together. This may not be required though anymore since we are not releasing this with XBackend support. I still think its smart to include (easier to relax this later)

TargetRefs []gwapiv1.LocalPolicyTargetReferenceWithSectionName `json:"targetRefs"`

// Action specifies the action to be taken when rules match.
// Evaluation logic:
// 1. ExternalAuth runs before all other Allow policies.
// 2. If an ExternalAuth server denies the request, the request is denied.
// 3. If it allows the request, processing continues for all other allow policies for that target.
// 4. The request is allowed only if all allow policies allow it.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#220 proposes that the request is allowed if any allow policy allows it.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we can let ExternalAuth deny early. Having it allow early has several concerns.

External Auth servers typically handle global context (like JWTs or tokens), but they don't necessarily anything about local boundaries inside the cluster. There may be cases where we still need our downstream policies (like SPIFFE identity matching or MCP method whitelisting) to validate that workload A is actually authorized to communicate with workload B, after external auth callout.

Hope thats clear

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like that proposal is still in discussion? v1alpha1 is getting cut with the current behavior -- it is still alpha and can change.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we can let ExternalAuth deny early. Having it allow early has several concerns.

This is not what #220 proposes. allow policies means inline policies. I am trying to suggest that we define the rules here to address #237.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to ask for some clarification on a user/group scenario with multiple rules having to be allowed, but I think this discussion is moreso about rules across different policies?

Also, we don't have support for groups or spiffe wildcards right now? So that wouldn't be relevant here (which is probably a good motivation for CEL/OIDC)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not what #220 proposes. allow policies means inline policies. I am trying to suggest that we define the rules here to address #237.

We currently propose Allow and ExternalAuth. We dont propose deny in this version given the consensus we got with other folks in the group. This rules are just outlining some guidance on how ExternalAuth and Allow should work across different policies (as @david-martin suggested)

David - right - I would really love to see CEL and OIDC support, hopefully you/gui can pick this up soon and we release it as part of 0.2.

(there is someone thats working on CEL right now, hopefully we incorporate this soon)

// +required
Action AccessPolicyActionType `json:"action"`

// ExternalAuth specifies an external auth filter to be used for authorization.
// Core support is limited to 1 ExternalAuth callout per target.
// +optional
ExternalAuth *gwapiv1.HTTPExternalAuthFilter `json:"externalAuth,omitempty"`

// Rules defines a list of rules to be applied to the target.
// An AccessPolicy must have at least one rule.
// +required
// +kubebuilder:validation:MinItems=1
// +kubebuilder:validation:MaxItems=10
// +listType=atomic
// +kubebuilder:validation:XValidation:rule="self.all(r, self.filter(x, x.name == r.name).size() == 1)",message="AccessRule names must be unique"
Comment thread
LiorLieberman marked this conversation as resolved.
Rules []AccessRule `json:"rules"`
}

// AccessPolicyActionType identifies a type of action for access policy.
// +kubebuilder:validation:Enum=Allow;ExternalAuth
type AccessPolicyActionType string

const (
// ActionTypeAllow is used to identify that the request should be allowed if rules match.
ActionTypeAllow AccessPolicyActionType = "Allow"
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be "LocalAuth" when the other Value of Enum is "ExternalAuth"?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that actions, will evolve to add Deny in the future as well. We already got some usecases that suggests deny will be needed.

Then you will have 3 actions. (1) this policy is an ALLOW policy, (2) this policy is a delegate to an external server and (3) this policy is a deny policy (if we ends up adding it in future releases)


// ActionTypeExternalAuth is used to identify that the request should be delegated to an external auth service if rules match.
ActionTypeExternalAuth AccessPolicyActionType = "ExternalAuth"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a contradiction here?

the request should be delegated to an external auth service if rules match

and

Evaluation logic:
// 1. ExternalAuth runs before all other Allow policies.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that if action: ExternalAuth and any rule (defined under the "rules" field) match - it goes to the externalAuth server for evaluation. If action: Allow and any rule (defined under the "rules" field) match - the evaluation of this is ALLOW.

Regardless of that, Evaluation logic between policies on the same target works in a way that if there is ExternalAuth, it before all other Allow policies. If the ExternalAuth server denies it - request is denied. If it allows it, you still need all other policies to allow it (unless they dont exist).

A concrete example:

action: extAuth
rules:

  • match path /foo
    target: Gateway1

action: Allow
rules:

  • match header bar
    target: Gateway1

If the request is "/foo", ExtAuthServer allows, and header bar is missing -- you still get the request denied.

)

// AccessRule specifies an authorization rule for a specified target.
type AccessRule struct {
// Name specifies the name of the rule.
// This follows the DNS Subdomain naming convention.
// See: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names
// +required
// +kubebuilder:validation:Pattern=`^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
Comment thread
LiorLieberman marked this conversation as resolved.
// +kubebuilder:validation:MinLength=1
// +kubebuilder:validation:MaxLength=63
Name string `json:"name"`
// Source specifies the source of the request.
// +required
Source AccessRuleSource `json:"source"`
// Authorization specifies the authorization rule to be applied to requests from the source.
// If omitted, all access from the specified source is allowed.
// +optional
Authorization *AuthorizationRule `json:"authorization,omitempty"`
Comment thread
LiorLieberman marked this conversation as resolved.
}

// AccessRuleSource specifies the source of a request.
//
// Type must be set to indicate the source type.
// Similarly, either SPIFFE or Serviceaccount can be set based on the type.
type AccessRuleSource struct {
Comment thread
LiorLieberman marked this conversation as resolved.
// +unionDiscriminator
// +required
Type AuthorizationSourceType `json:"type"`

// spiffe specifies an identity that is matched by this rule.
//
// spiffe identities must be specified as SPIFFE-formatted URIs following the pattern:
// spiffe://<trust_domain>/<workload-identifier>
//
// The exact workload identifier structure is implementation-specific.
// This will likely change in the future.
//
// SPIFFE identities for authorization can be derived in various ways by the underlying
// implementation. Common methods include:
// - From peer mTLS certificates: The identity is extracted from the client's
// mTLS certificate presented during connection establishment.
// - From IP-to-identity mappings: The implementation might maintain a dynamic
// mapping between source IP addresses (pod IPs) and their associated
// identities (e.g., Service Account, SPIFFE IDs).
// - From JWTs or other request-level authentication tokens.
//
// +optional
SPIFFE *AuthorizationSourceSPIFFE `json:"spiffe,omitempty"`

// serviceAccount specifies a Kubernetes Service Account that is
// matched by this rule. A request originating from a pod associated with
// this Service Account will match the rule.
//
// The Service Account listed here is expected to exist within the same
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by trust domain, do we mean same kubernetes cluster, or same namespace?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its configurable. Often times it would be a cluster identifier, but its not strictly required.
Here is how it could commonly be: spiffe://<trust_domain>/ns/<namespace>/sa/<serviceaccount>

// trust domain as the targeted workload. Cross-trust-domain access should
// instead be expressed using the `SPIFFE` field.
// +optional
ServiceAccount *AuthorizationSourceServiceAccount `json:"serviceAccount,omitempty"`
}

// AuthorizationSourceType identifies a type of source for authorization.
// +kubebuilder:validation:Enum=ServiceAccount;SPIFFE
type AuthorizationSourceType string

const (
// AuthorizationSourceTypeSPIFFE is used to identify a request matches a SPIFFE Identity.
AuthorizationSourceTypeSPIFFE AuthorizationSourceType = "SPIFFE"

// AuthorizationSourceTypeServiceAccount is used to identify a request matches a ServiceAccount from within the cluster.
AuthorizationSourceTypeServiceAccount AuthorizationSourceType = "ServiceAccount"
)

// +kubebuilder:validation:Pattern=`^spiffe://[a-z0-9._-]+(?:/[A-Za-z0-9._-]+)*$`
type AuthorizationSourceSPIFFE string

type AuthorizationSourceServiceAccount struct {
// Namespace is the namespace of the ServiceAccount
// If not specified, current namespace (the namespace of the policy) is used.
// +optional
Namespace string `json:"namespace,omitempty"`

// Name is the name of the ServiceAccount.
// +required
Name string `json:"name"`
}

// AuthorizationRule defines the specific authorization criteria that requests must meet.
type AuthorizationRule struct {
Comment thread
LiorLieberman marked this conversation as resolved.
// +unionDiscriminator
// +required
Type AuthorizationRuleType `json:"type"`

// MCP defines MCP-specific matching criteria.
// If omitted, the policy does not check MCP-level parameters, allowing all MCP traffic that
// successfully passes through the matched HTTP routing envelope.
// +optional
MCP MCPAttributes `json:"mcp,omitempty"`
Comment thread
LiorLieberman marked this conversation as resolved.
}

// MCPAttributes defines the protocol-specific attributes for MCP authorization.
type MCPAttributes struct {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this imply that the rules are basically based on MCP tool name and parameters?

Copy link
Copy Markdown
Member Author

@LiorLieberman LiorLieberman May 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for now yes. The group discussed to add additional support for "Inline" ways to specify other requests attributes like path, headers, etc.

That said, once CEL support is added you will be able to do more granular things with CEL. You would have AuthorizationRuleTypeCEL (in addition to the AuthorizationRuleTypeInline). See this slide for the general idea

// Methods is a list of specific MCP functional methods to match.
// If specified, only MCP requests with a method
// that matches one of these items will be authorized.
// If empty or omitted, no method-level allowlisting is applied, meaning all
// MCP methods (e.g., all tools, prompts, and resources) are permitted.
// +kubebuilder:validation:MaxItems=10
Comment thread
LiorLieberman marked this conversation as resolved.
// +optional
// +listType=map
// +listMapKey=name
Methods []MCPMethod `json:"methods,omitempty"`
}

// MCPMethod defines a specific MCP method and its associated parameters.
// +kubebuilder:validation:XValidation:rule="has(self.params) && self.params.size() > 0 ? self.name in ['prompts/get', 'tools/call', 'resources/subscribe', 'resources/unsubscribe', 'resources/read'] : true",message="Params can only be specified for get, call, subscribe, unsubscribe, or read methods"
type MCPMethod struct {
// Name is the MCP method to match against (e.g., 'tools/call').
// Allowed values:
// 1. 'tools', 'prompts', 'resources': Matches all sub-methods under these categories.
// 2. 'prompts/list', 'tools/list', 'resources/list', 'resources/templates/list'.
// 3. 'prompts/get', 'tools/call', 'resources/subscribe', 'resources/unsubscribe', 'resources/read'.
// Parameters cannot be specified for categories 1 and 2.
Comment thread
LiorLieberman marked this conversation as resolved.
Comment thread
LiorLieberman marked this conversation as resolved.
// +required
Name MCPMethodName `json:"name"`

// Params allows matching against specific arguments in the MCP request.
// Only valid for 'get', 'call', 'subscribe', 'unsubscribe', and 'read' methods.
Comment thread
LiorLieberman marked this conversation as resolved.
// If empty or omitted, parameter-level allowlisting is not applied, meaning the method
// is authorized regardless of the arguments passed in the request.
// +optional
// +listType=set
// +kubebuilder:validation:MaxItems=10
Params []MCPMethodParam `json:"params,omitempty"`
}

// +kubebuilder:validation:MaxLength=20
Comment thread
LiorLieberman marked this conversation as resolved.
type MCPMethodParam string

// MCPMethodName defines the allowed MCP methods for matching.
// +kubebuilder:validation:Enum=tools;prompts;resources;prompts/list;tools/list;resources/list;resources/templates/list;prompts/get;tools/call;resources/subscribe;resources/unsubscribe;resources/read
type MCPMethodName string

// AuthorizationRuleType identifies a type of authorization rule.
// +kubebuilder:validation:Enum=Inline
type AuthorizationRuleType string

const (
// AuthorizationRuleTypeInline is used to identify authorization rules
// declared as attributes inside the policy (inline)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does policy mean?

why is (inline) needed here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Policy mean the CRD. let me add a clarification.
Inline means the rules are defined in the policy vs CEL which is a more dynamic expression that can allow variety of things.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can discuss on naming if this is confusing

AuthorizationRuleTypeInline AuthorizationRuleType = "Inline"
)

const (
// PolicyConditionAccepted indicates whether the policy has been accepted by the controller.
//
// Possible reasons for this condition to be True are:
//
// * "Accepted"
//
// Possible reasons for this condition to be False are:
//
// * "LimitPerTargetExceeded"
//
PolicyConditionAccepted gwapiv1.PolicyConditionType = "Accepted"

// This reason is used with the "Accepted" condition when the policy
// has been accepted by the controller.
PolicyReasonAccepted gwapiv1.PolicyConditionReason = "Accepted"

// This reason is used with the "Accepted" condition when the policy
// was rejected because the maximum number of policies per target was exceeded.
PolicyLimitPerTargetExceeded gwapiv1.PolicyConditionReason = "LimitPerTargetExceeded"
Comment thread
LiorLieberman marked this conversation as resolved.
)

// AccessPolicyStatus defines the observed state of AccessPolicy.
type AccessPolicyStatus struct {
// For Policy Status API conventions, see:
// https://gateway-api.sigs.k8s.io/geps/gep-713/#the-status-stanza-of-policy-objects
//
// Ancestors is a list of ancestor resources (usually Gateway or Mesh) of
// the policy target which are enforcement points for the
// policy, and the status of the policy with respect to each ancestor.

// +required
// +listType=atomic
// +kubebuilder:validation:MaxItems=16
Ancestors []gwapiv1.PolicyAncestorStatus `json:"ancestors"`
}

// +genclient
// +kubebuilder:object:root=true
// +kubebuilder:subresource:status

// XAccessPolicy is the Schema for the accesspolicies API.
type XAccessPolicy struct {
metav1.TypeMeta `json:",inline"`

// metadata is a standard object metadata.
// +optional
metav1.ObjectMeta `json:"metadata,omitempty"`

// spec defines the desired state of AccessPolicy.
// +required
Spec AccessPolicySpec `json:"spec"`
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the k8s CRD convention naming would be something like this

	Spec XAccessPolicySpec `json:"spec"`

I wonder why we have two different naming here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. Looks like we have not done this in the Gateway community. I have no strong opinion, but its going to be more nice code wise to not call v1alpha1.XAcessPolicySpec. The X prefix serves primarily the purpose of safe upgrades to standard channel and to explicitly indicate that this is an experimental resource

https://github.com/kubernetes-sigs/gateway-api/blob/main/apisx/v1alpha1/xbackendtrafficpolicy_types.go
https://github.com/kubernetes-sigs/gateway-api/blob/main/apisx/v1alpha1/xmesh_types.go


// status defines the observed state of AccessPolicy.
// +optional
Status AccessPolicyStatus `json:"status,omitempty"`
}

// +kubebuilder:object:root=true

// XAccessPolicyList contains a list of AccessPolicy.
type XAccessPolicyList struct {
metav1.TypeMeta `json:",inline"`
// metadata is a standard list metadata.
// +optional
metav1.ListMeta `json:"metadata,omitempty"`
Items []XAccessPolicy `json:"items"`
}
19 changes: 19 additions & 0 deletions api/v1alpha1/doc.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
/*
Copyright The Kubernetes Authors.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

// +k8s:deepcopy-gen=package
// +groupName=agentic.networking.x-k8s.io
package v1alpha1
Loading
Loading