-
Notifications
You must be signed in to change notification settings - Fork 31
Add v1alpha1 api #259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add v1alpha1 api #259
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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. | ||
| .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))" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
|
@@ -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 | ||
|
|
||
|
|
||
| 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'" | ||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why
If we decide to keep supporting Backend-targeted AccessPolicy in the reference implementation, we should allow the target to be either Gatway or Backend.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we validate the targetRef in control plane?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is about not mixing targetRefs?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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)
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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" | ||||
|
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" | ||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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"?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a contradiction here?
and
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This means that if 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
action: Allow
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])?)*$` | ||||
|
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"` | ||||
|
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 { | ||||
|
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 | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. by trust domain, do we mean same kubernetes cluster, or same namespace?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||||
| // 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 { | ||||
|
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"` | ||||
|
LiorLieberman marked this conversation as resolved.
|
||||
| } | ||||
|
|
||||
| // MCPAttributes defines the protocol-specific attributes for MCP authorization. | ||||
| type MCPAttributes struct { | ||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||||
|
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. | ||||
|
LiorLieberman marked this conversation as resolved.
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. | ||||
|
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 | ||||
|
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) | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what does why is
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Policy mean the CRD. let me add a clarification.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" | ||||
|
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"` | ||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the k8s CRD convention naming would be something like this I wonder why we have two different naming here?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||||
|
|
||||
| // 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"` | ||||
| } | ||||
| 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)