Add Path field to NetworkService and NetworkServiceEndpoint

[NikitaSkrynnik]

No description provided.

[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 :)

[edwarnicke]

Why do we have PathSegment and Path when we don't use them?

[NikitaSkrynnik]

Hello, it's temporary solution. We have next options for this data structure:

1. Use just an array of tokens, because in our OPA policies we check only them
2. Make a similar data structure and place it in SDK, near chain elements that are related to OPA for Registry
3. Leave this data structure in API as is
4. Make Path data structure common for NetworkService and Registry and move it to another place in API repo, because path for registry and path for networkservice are the same

What do you think of it?

[denis-tingaikin]

@edwarnicke I think we can go with option 2.

Because then we'll need only to add

repeated string path_ids = 4;

for NetworkServices/NetworkServiceEndpoints in api repo

[edwarnicke]

Sounds good :)

[denis-tingaikin]

Looked quickly the previous time.

Now, it's looking good to me.

@glazychev-art , @LionelJouin Could you have a look? 😉