Add Path field to NetworkService and NetworkServiceEndpoint

[denis-tingaikin]

@LionelJouin , @edwarnicke , @fkautz

Let's discuss all possible solutions for Path.

Motivation

We want to make registry operations safe and use zero trust. Also, we already have a positive experience with OPA and networkservicemesh.Path

Solution

Add networkservicemesh.Path to registry services.

Registry services are https://github.com/networkservicemesh/api/blob/main/pkg/api/registry/registry.proto#L44-L54

NSE/NS entries are https://github.com/networkservicemesh/api/blob/main/pkg/api/registry/registry.proto#L9-L13 and https://github.com/networkservicemesh/api/blob/main/pkg/api/registry/registry.proto#L35-L42

Options

Option 1: Add Path directly into NSE/NS entries

So we can just add Path as a field for those structures.

Pros:

1. It's simple.
2. It's cheap. We don't need to modify the whole SDKs repos.

Cons:

1. We'll store the Path in etcd database of Kubernetes (TODO: Is this a real problem?)

Option 2: Wrap NSE/NS entries

We also can just wrap NSE/NS entries with new messages:

message NetworkServiceRegistration {
    NetworkService network_service = 1;
    Path path = 2;
}

message NetworkServiceEndpointRegistration {
    NetworkServiceEndpoint network_service_endpoint = 1;
    Path path = 2;
}

Pros:

1. We're not storing Path in CRD (for k8s)

Cons:

1. It's hard to add. We need to change the whole SDK.

Option 3: Add path to grpc metdata

grpc metadata is just KV map

type MD map[string][]string

MD is used for tokens and so on. Also, it transfers with TLS if it is enabled (in our case we're using TLS from the Spire)

Pros:

1. We're not storing Path in CRD (for k8s)
2. It's cheap. We don't need to modify the whole SDKs repos.

Cons:

1. This method is not enough investigated

TODO: Your option

[denis-tingaikin]

@edwarnicke , @fkautz , @LionelJouin

Any thoughts are super welcome :)