Skip to content
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 EventPolicy type #7971

Closed
creydr opened this issue Jun 10, 2024 · 4 comments · Fixed by #7995
Closed

Add EventPolicy type #7971

creydr opened this issue Jun 10, 2024 · 4 comments · Fixed by #7995
Assignees
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. triage/accepted Issues which should be fixed (post-triage)

Comments

@creydr
Copy link
Member

creydr commented Jun 10, 2024

As the Eventing Authorization feature track describes, the EventPolicy is a new resource type, defining the allowed subjects to a list of targets.

It can look like the following:

apiVersion: eventing.knative.dev/v1alpha1
kind: EventPolicy
metadata:
  name: event-policy
  namespace: default
spec:
  to:
    - ref: # A direct reference
        apiVersion: eventing.knative.dev/v1
        kind: Broker
        name: my-broker
    - selector: # Object selector, gvk-specific
        apiVersion: eventing.knative.dev/v1
        kind: Broker
        matchLabels:
          app: my-broker

  from:
    - ref:
        apiVersion: sources.knative.dev/v1
        kind: ApiServerSource
        name: my-source
        namespace: my-ns
    - sub: system:serviceaccount:my-ns:my-app
    - sub: system:serviceaccount:my-ns:my-source
    - sub: "system:serviceaccount:other-ns:*"

status:
  from:
    - system:serviceaccount:my-ns:my-source-oidc-sources.knative.dev-apiserversource 
    - system:serviceaccount:my-ns:my-app
    - system:serviceaccount:my-ns:my-source
    - "system:serviceaccount:other-ns:*"

  conditions:
    - type: Ready
      status: "True"
    - type: SubjectsResolved
      status: "True"

Therefor we should do the following:

  • add this new type under pkg/apis/eventing/v1alpha1 and be defined as the following:
    // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
    type EventPolicy struct {
        metav1.TypeMeta   `json:",inline"`
        metav1.ObjectMeta `json:"metadata,omitempty"`
    
        Spec   EventPolicySpec   `json:"spec,omitempty"`
        Status EventPolicyStatus `json:"status,omitempty"`
    }
    
    type EventPolicySpec struct {
        // To lists all resources for which this policy applies.
        // Resources in this list must act like an ingress and have an audience.
        // The resources are part of the same namespace as the EventPolicy.
        // An empty list means it applies to all resources in the EventPolicies namespace
        // +optional
        To []EventPolicySpecTo `json:"to,omitempty"`
    
        // From is the list of sources or oidc identities, which are allowed to send events to the targets (.spec.to).
        From []EventPolicySpecFrom `json:"from,omitempty"`
    }
    
    type EventPolicyStatus struct {
        duckv1.Status `json:",inline"`
    
        // From is the list of resolved oidc identities from .spec.from
        From          []string `json:"from,omitempty"`
    }
    
    type EventPolicySpecTo struct {
        // Ref contains the direct reference to a target
        // +optional
        Ref      *EventPolicyToReference `json:"ref,omitempty"`
    
        // Selector contains a selector to group targets
        // +optional
        Selector *EventPolicySelector    `json:"selector,omitempty"`
    }
    
    type EventPolicySpecFrom struct {
        // Ref contains a direct reference to a resource which is allowed to send events to the target.
        // +optional
        Ref       *EventPolicyFromReference `json:"ref,omitempty"`
        
        // Sub sets the OIDC identity name to be allowed to send events to the target. 
        // It is also possible to set a glob-like pattern.
        // +optional
        Sub       *string                   `json:"sub,omitempty"`
    }
    
    type EventPolicyToReference struct {
        // API version of the referent.
        APIVersion string `json:"apiVersion,omitempty"`
    
        // Kind of the referent.
        // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
        Kind string `json:"kind"`
    
        // Name of the referent.
        // More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
        Name string `json:"name"`
    }
    
    type EventPolicyFromReference struct {
        // API version of the referent.
        APIVersion string `json:"apiVersion,omitempty"`
    
        // Kind of the referent.
        // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
        Kind string `json:"kind"`
    
        // Name of the referent.
        // More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
        Name string `json:"name"`
    
        // Namespace of the referent.
        // More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
        // This is optional field, it gets defaulted to the object holding it if left out.
        // +optional
        Namespace string `json:"namespace,omitempty"`
    }
    
    type EventPolicySelector struct {
        *metav1.LabelSelector `json:",inline"`
        *metav1.TypeMeta      `json:",inline"`
    }
    
    // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
    
    type EventPolicyList struct {
        metav1.TypeMeta `json:",inline"`
        metav1.ListMeta `json:"metadata,omitempty"`
        Items           []EventPolicy `json:"items"`
    }
  • Create the CRD for this type under config/core/resources/eventtype.yaml
  • Add a client for the EventPolicy type
    This can be done, by adding
    // +genclient
    
    to the EventPolicy type. Check on the Broker for an example.

Hints:

  • To generate the deepcopy functions for the EventPolicy type, you need to add the "new" eventing:v1alpha1 group:version to the ./hack/update-codegen.sh script
  • Run ./hack/update-codegen.sh to run the code generators to create the deepcopy methods and clients
  • We don't have yet automation to create the CRD file. But you could check on kubebuilder how they create CRDs and then copy it over 🤷
  • Check for example on the Broker type for the different generator annotations

Additional hints for new contributors before starting with this issue:

  1. When the issue has the Draft status, the issue is subject to change and thus should not be started to be worked on
  2. Make sure you've read and understood the CONTRIBUTING.md guidelines
  3. Make sure you're able to run Knative Eventing locally and run at least the unit tests.
  4. When you feel comfortable with this issue, feel free to assign it to you (e.g. by commenting /assign) and ask any question you have. Please be aware that we might unassign you, if we don't see any progress from your side to give other contributors also a chance to work on this issue.
@creydr creydr added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Jun 10, 2024
@creydr creydr removed the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label Jun 11, 2024
@pierDipi
Copy link
Member

We don't have yet automation to create the CRD file. But you could check on kubebuilder how they create CRDs and then copy it over 🤷

This one can be help, it's not perfect though https://github.com/knative/eventing/blob/main/cmd/schema/main.go

@pierDipi
Copy link
Member

/assign

@matzew
Copy link
Member

matzew commented Jun 12, 2024

Do we also want to have some rules for restricting the event types? E.g. does each allowed addressable send anything ?

@creydr
Copy link
Member Author

creydr commented Jun 12, 2024

Do we also want to have some rules for restricting the event types? E.g. does each allowed addressable send anything ?

Not from the beginning. But we have this as a possible improvement listed in the FT to allow "more precise filter mechanisms" which could include to filter on event types too.

@creydr creydr added the triage/accepted Issues which should be fixed (post-triage) label Jun 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. triage/accepted Issues which should be fixed (post-triage)
Projects
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

3 participants