More Pod attributes for PDP: SA and labels

[zivnevo]

This PR adds more client-Pod attributes for the PDP to consider. We now have:

• clusterlink/metadata.clientName - the value of the Pod's label app (if it has one)
• clusterlink/metadata.clientNamespace - the Pod's namespace
• clusterlink/metadata.clientServiceAccount - the Pod's service account
• client/metadata.<key> - the value of the Pod's label <key> (one such attribute for each label)

Open questions:

• Do we still need clusterlink/metadata.clientName? Users can now simply use client/metadata.app instead
• How should we handle Pods for which CL has no info (yet)? Deny their request? Provide the PDP with an empty set of attributes?
• E2E testing issue: how to make sure Pod info was read by CL before the Pod can start sending requests? Currently, the solution is sleep 3. Any better ideas?

[elevran]

This PR adds more client-Pod attributes for the PDP to consider. We now have:

• clusterlink/metadata.clientName - the value of the Pod's label app (if it has one)
• clusterlink/metadata.clientNamespace - the Pod's namespace
• clusterlink/metadata.clientServiceAccount - the Pod's service account
• client/metadata.<key> - the value of the Pod's label <key> (one such attribute for each label)

Is there a need to designate client vs service in attribute names? clusterlink/metadata.clientNamespace can just be clusterlink/metadata.namespace...

Open questions:

• Do we still need clusterlink/metadata.clientName? Users can now simply use client/metadata.app instead

IMO, we do not. I think it is up to the user to set the labels they care about and we should not treat app any different than other labels.

• How should we handle Pods for which CL has no info (yet)? Deny their request? Provide the PDP with an empty set of attributes?

I would propose we deny on lack of sufficient context, to comply with principles of default deny, and let the client retry (e.g., we could consider reset or timeout as the response). They could have properties that would deny the request so proceeding with insufficient knowledge seems to me as the wrong thing security wise.

• E2E testing issue: how to make sure Pod info was read by CL before the Pod can start sending requests? Currently, the solution is sleep 3. Any better ideas?

Tests can explicitly confirm the Pod has IP then wait 1s or so?

[zivnevo]

After some rethinking, I now believe it's better for client and service to have distinct attribute prefixes. The main reason is that they don't have the exact same set of attributes (e.g., only clients have a service account, only services have a name). Having distinct prefixes will make it easier to ensure users are not using unavailable attributes in their policies. In addition, distinct prefixes make all attributes share the same pattern - a more consistent scheme.

My current proposal for attribute names (inspired by K8s well-known labels):

Client (Pod):

• client.clusterlink.net/namespace - pod namespace
• client.clusterlink.net/service-account - pod service account
• client.clusterlink.net/labels.<label-key> - pod labels

  Service (export):

• export.clusterlink.net/name - Export name
• export.clusterlink.net/service-name - the name of the K8s Service behind the Export (not currently implemented)
• export.clusterlink.net/namespace - Export namespace
• export.clusterlink.net/labels.<label-key> - Export labels
• export.clusterlink.net/service-labels.<label-key> - the labels of the k8s Service behind the Export (not currently implemented)

  Peer:

• peer.clusterlink.net/name - Peer name
• peer.clusterlink.net/labels.<label-key> - Peer labels (not currently implemented, to be set when calling clusterlink deploy peer)

@elevran , @orozery , @kfirtoledo - your thoughts?