Security requirements

[vaikas]

This issue tracks the requirements and design for the security of the data plane.
@evankanderson assigning to you as I know you were looking at the various aspects of this.

[evankanderson]

A few short thoughts and some doc links:

We started a doc here, but I don't think I was able to get anyone else to add their requirements. We also have some interesting internal requirements which I'll try to synthesize into public form, though they may boil down to "custom admission control may be needed here".

For data plane access control, I see four options:

1. Limit access by using DNS -- restrict who can resolve the DNS name of the channel, possibly including a nonce in the actual expected hostname to reduce ability to guess at the endpoint.
   Cons: probably technically infeasible with kubernetes or other off the shelf resolvers (DNS does not have strong mechanisms for authenticating DNS clients). A name resolution leak (i.e. by passing results from one container to another) is an access control compromise. Feels like this is building a house of cards.

2. Limit access by using IP level controls, i.e. kubernetes NetworkPolicy.
   Pros: probably widely available via CNI providers: Calico/Canal, Weave, kube-router, Cilium, or Romana support NetworkPolicy. No need for service mesh installation.
   Cons: No fine-grained support for distinguishing below the IP level (hostname, path). May be difficult to support cross-cluster integrations. Encryption support dependent on CNI provider (maybe only Calico, Weave?)

3. Embrace the use of Istio/service mesh, and use layer-7 access control and policy to control access.
   Pros: Supports fine-grained control (path-level and hostname-level) access control. Supports access control based on application-level identity which should work from off-cluster. Support for encryption provided by the service mesh.
   Cons: Requires running Istio in sidecar mode, which adds cold-start latency for Serving. Adds a hard dependency on Istio.

4. Implement access control in application software.
   Cons: Requires all application software to implement access control: via shared libraries in multiple languages, or via sidecar (see item 3 for sidecar approach). Introduces versioning and possible security issues when libraries are inconsistently applied. Still needs a mechanism to push access control policy to all participating nodes. This basically ignores the problem and pushes it on developers rather than solving it.

[evankanderson]

Options 2 and 3 seem the most feasible. One possible additional option (suggested by @Harwayne) was to have an abstract access control interface which would determine the concrete source/destination which should be allowed and then multiple implementations of the access control interface for different option 2 or option 3 providers.

Note that doing this would either require that we think carefully about IP-level segregation of channel ingresses (and possibly also sinks) or that running in option 2 mode would be only a partial security solution.

[grantr]

Punting this to 0.4. We have a start but nothing that could be called a design proposal.
/milestone v0.4.0

[vaikas]

Let's break this down to Generic Security Requirements for now, then gather the requirements and then generate more fine grained issues to track.

[evankanderson]

This needs to be broken down into smaller steps. It may be worth using a Project to track this. Some sample stories/steps:

• List of minimal "allowable" sharing cases.
• Implementation of TLS between data plane components.
• Peer-to-peer authentication technology between data plane components (recommend OAuth?)
• Decision about how to perform authz between data plane components (i.e. which identity can send events). Possibly define new objects to describe the allowed connections.
• Implementation of authz given decision above.