Add V2 TCP traffic permissions

[erichaberkorn]

Description

• Change the name of intentions to traffic permissions in pbproxystate.
• Add the protobufs for the pbproxystate L4 traffic permissions.
• Add the code to generate Envoy RBAC from proxystate's L4 traffic permissions.
• Differences from v1:
  • Configuring a single traffic permission turns on default allow.
  • Traffic permissions are enforced across two RBAC filters.

Testing & Reproduction steps

• This piggybacks on top of the existing xDS RBAC tests differently than other tests. The RBAC tests are tightly coupled with the existing xDS generation, so this PR allows us to define v2 traffic permissions that have equivalent xDS snapshots to v1 intentions (even though they don't reuse any of the v1 logic).
• Defines a few new xDS RBAC tests that only apply to new v2 traffic permissions.
• 92.6% test coverage. The only non-error missing test coverage is related to XFCC principals. They are currently unused and only there to ensure we are setting up the correct long term foundations.

PR Checklist

• updated test coverage
• external facing docs updated
• appropriate backport labels added
• not a security concern (This is definitely a security concern)

[ishustava]

Thanks for doing this! I only reviewed the protos and had some feedback which I think will impact the rest of the code so I didn't review that yet.

[ishustava]

proxystateconverter only coverts v1 stuff to v2 stuff? Is that the right place for this logic? It feels like something that the code that generates IR (i.e. sidecar proxy controller) should figure out.

[erichaberkorn]

Yeah, this was wrong. I changed this to xDS controller.

[ishustava]

Would it be xds controller though? The xDS controller should only be responsible for filling in service endpoints, leaf certs and CA certs. I think it should be sidecar-proxy controller

[erichaberkorn]

These tests are a bit different from the other v2 xds tests because we are using completely different code in v1 and v2. The tests are colocated and sharing the same golden files so we can visually inspect the v1 and v2 intentions / traffic permissions to show that they are equivalent.

[ishustava]

Leaving some more comments mostly on the structure. I think we can probably un-nest some things and make the xds generation do less logic and have envoy do that logic for us. Sorry if I haven't communicated it well on the RFC! Happy to chat about any of this!

[ishustava]

should we rename this? When consul is default deny, we'd still need to know that we need to add an empty rbac filter.

[erichaberkorn]

I removed this field because we can figure this out from other data.

[ishustava]

Would it be xds controller though? The xDS controller should only be responsible for filling in service endpoints, leaf certs and CA certs. I think it should be sidecar-proxy controller

[ishustava]

Why is the structure different from L4?

[erichaberkorn]

I updated this based on our discussion earlier.

[ishustava]

Since we're only doing L4 I wonder if we should omit it altogether. Otherwise, what do you think if we do the following:

message L7Principal {
  L7PrincipalID principal_id = 1;
  repeated L7PrincipalID exclude_principal_ids = 2;
}

message L7PrincipalID {
  oneof id {
    MTLSAuthPrincipal mtls = 1;
    XFCCPrincipal xfcc = 2;
    JWTPrincipal jwt = 3;
  }
}

message MTLSAuthPrincipal {
  string spiffe_regex = 1;
}

message XFCCPrincipal {
  string spiffe_regex = 1;
}

message JWTPrincipal {
  // todo:
}

message L7TrafficPermissions {
  repeated L7Policy allow_policies = 1;
  repeated L7Policy deny_policies = 2;
}

message L7Policy {
  repeated L7Principal principals = 1;
  repeated L7Rule rules = 2;
}

message L7Rule {
  L7PolicyRule rule = 1;
  repeated L7PolicyRule exclude_rules = 2;
}

message L7PolicyRule {
  string path_exact = 1;
  string path_prefix = 2;
  string path_regex = 3;

  // methods is the list of HTTP methods. If no methods are specified,
  // this rule will apply to all methods.
  repeated string methods = 4;

  RuleHeader header = 5;
}

The idea I have here with principals based on current usage is that it seems that today we use either Authenticated, or Header (only for xfcc) or Segment (only for JWT). Structuring it this way would allow us for more flexibility when we implement JWT without changing the API too much.

The naming with L7 is hard so I ended up using the word Policy but instead of repeating Permission again.

[ishustava]

Are you thinking to do this for backward compat?

[erichaberkorn]

Yeah, exactly. So we can compare the output to existing golden files. It probably won't make sense to do this for long, but it feels nice in the short term.

[ishustava]

It seems like with this you could end up with a list of lists of allow and deny principals which will result in many RBAC filters (i.e. more than 2) unless we flatten it into two? I was imagining that we would combine all allow policies into one rbac filter and all deny policies into one rbac which will then mean that we will always have at most two rbac filters for any filter chain. This would then result in in-lining this object here:

message L4TrafficPermissions {
    repeated L4Principal allow_principals = 1;
    repeated L4Principal deny_principals = 2;
}

This would then be similar to how computed traffic permissions are structured also.

[erichaberkorn]

Yeah, it was a bit awkward, but ended up getting flattened into two or fewer RBAC filters. The solution we came up with earlier fixes the awkwardness.

[ishustava]

I was imagining that we would instead put each AllowPrincipal into a policy with the index of that AllowPrincipal object. This would allow us to avoid constructing the orPrincipal for all allow/deny principals.