search

knative / eventing

Event-driven application platform for Kubernetes
https://knative.dev/docs/eventing
Apache License 2.0
1.41k stars 588 forks source link

Add or surface serviceAccountName to source/channel API #2365

Closed yolocs closed 3 years ago

yolocs commented 4 years ago

Background As ongoing work for https://github.com/knative/eventing/issues/1449, we want to move on the direction to have identity-based service-to-service authorization. The "identity" usually means k8s service accounts.

Problem Currently, when creating a channel (or source), there is no consistent way to specify (or at least surface) a service account to run the underlying workload. When the control plane of a higher level component (e.g. broker, flows) wants to create channel(s), it doesn't know the identity of the channel and thus it cannot effectively set up authorization policies.

Example: In the current broker implementation, it uses the channel template to create a channel but it cannot specify a service account for the channel. The broker filter today has to blindly accept all incoming events because it doesn't know which service account the channel will use to send events to it.

Persona: Developer, operator

Exit Criteria serviceAccountName becomes part of the spec that's accepted and honored by all channel/source implementation. Or maybe at least there is a consistent way to surface the what service account is used by a channel/source to send events.

yolocs commented 4 years ago

@lionelvillard @vaikas

lionelvillard commented 4 years ago

How does this relate to the various authentication and authorization capability provided by the backend channels/sources? For instance, Kafka allows fined-grained ACLs. Are you suggesting SA should be used for configuring ACLs?

yolocs commented 4 years ago

At the moment I'm only thinking about service-to-service auth where the policy will be defined in some sort of knative policy CRD. And there will be policy enforcer for each opt-in workload. I'm still working on a detailed design.

In general, I think knative auth can co-exist with any application native auth capabilities. E.g. you can opt-out your kafka channel for policy enforcement and continue to use its own ACL to control who can access it. One caveat is application native auth capability varies. It lacks a common way to configure. This could result in higher level component (e.g. broker, flows) being unable to secure them effectively if you choose native auth.

lionelvillard commented 4 years ago

Can you give an example of service-to-service auth? Do you mean Knative eventing services (like broker-filter) or services in general?

yolocs commented 4 years ago

Services in general. Eventing services are still services. A channel is a service (or services like ingress and egress could be different services) with identity A and a receiver is a service with identity B.

The policy defines whether B should accept events from A. The scope of security policy no longer fits into eventing (or serving). But we haven't figured out where we should put the security policy stuff

github-actions[bot] commented 3 years ago

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.