Denying all traffic by default

[aanandr]

The Traffic Access Control spec (https://github.com/servicemeshinterface/smi-spec/blob/master/traffic-access-control.md#tradeoffs) talks about all traffic being denied by default. I would like to know why. The spec says due to the additive nature but its still not clear to me.
Customers usually want to see what the interactions between various microservices look like before deciding what access control policies to create. We could always allow all traffic to begin with and then later plumb a policy that says a certain service S1 can accept traffic only from S2 and S3 and still achieve restricted access. We dont even need deny policies. In some ways this is how K8S Network Policies work - before you apply the policy all Pods can talk to each other and K8S policies then define ingress and egress allow rules for a Pod.

[grampelberg]

Great question! TLDR, we're following Kubernetes guidance on this one. I used to have a good explanation of why they did that, but my google-fu is failing me this morning. The use case you're mentioning is super important and there's a discussion in the spec about how to do that (at least for metrics). You'd add a allow all policy to your cluster either at install time by default or when the access control was enabled.

By doing this as configuration, instead of as part of the spec is that it is explicit, auditable and easy to debug. In addition to that, here's my reasons for wanting it to be only additive:

• Security teams are very unhappy with everything open by default, it makes auditing hard and controlling access in the system difficult to reason about.
• You can't describe policy based off only deny rules, requiring allow and deny.
• From an implementation perspective, figuring out precedence between deny and allow` is super hard.
• Reasoning about allow and deny rules as a user is super hard. Back to the same issues that implementations have but in real time.

[aanandr]

@grampelberg - thanks for the explanation. I took a look at the metrics spec but couldnt find it. Maybe its hidden somewhere and i missed it.
Looks like you are suggesting a couple of options for an "allow all" policy

1. Enable it during cluster creation (i assumed you meant mesh creation)
2. When access control is enabled - did you mean to say access control is like a flag which when enabled for the mesh will automatically allow all traffic?

I had some follow up questions

1. In option 1 above, once the customer knows the list of filtering rules to apply how will he apply them? Will he reset his mesh to deny all traffic and then use Traffic Control Policies (our SMI spec)?
2. What about in the second option?

[grampelberg]

Enable it during cluster creation (i assumed you meant mesh creation)

Yup, mesh creation. The install of the mesh would add a Traffic Control Policy that is permissive. When a user decides that they'd lock things down, they'd slowly make the initial policy less and less permissive while adding more specific configuration.

When access control is enabled - did you mean to say access control is like a flag which when enabled for the mesh will automatically allow all traffic?

You could do it that way I guess. I was just thinking of optionally installing the original permissive policy. For folks who want it locked down from the beginning, during mesh installation they could just skip the permissive policy.

[shashankram]

@grampelberg Is there a permissive policy available in SMI or is this just an idea at this moment?

[grampelberg]

We could probably make it easier, but this works for now:

apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRouteGroup
metadata:
  name: everything
matches:
- name: api
  pathRegex: "/.*"
  methods: ["*"]
---
kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
  name: full-access
  namespace: default
destination:
  kind: ServiceAccount
  name: default
  namespace: default
specs:
- kind: HTTPRouteGroup
  name: permissive
sources:
- kind: ServiceAccount
  name: default
  namespace: default

[aanandr]

@grampelberg - one concern i had was the following - since we are deny all to begin with and need a policy such as the above to become allow-all, keeping up with the addition of new services and service accounts would be challenging. It will require a lot of sidecar proxy configuration just for one service addition. Wouldnt this become a perf problem then?

[grampelberg]

You'll get performance issues pretty much no matter which way you go on this one, though that'll be primarily RSS related performance issues and not inline latency.

That said, I think we could change that spec around a little to make the permissive policies less specific.

[aanandr]

Isnt the above proposal pretty generic already for the permissive policy? What did you have in mind?

[grampelberg]

@aanandr I was thinking we could do some wildcards like k8s RBAC does.