Use ServiceIdentity type in catalog APIs instead of service.K8sServiceAccount

[shashankram]

The type identity.ServiceIdentity was introduced to abstract the the identities assigned to services. Use this in catalog APIs instead of k8s.ServiceAccount to not leak Kubernetes primitives and identity abstraction across the MeshCataloger API boundaries.

This is where the current K8sServiceAccount is declared: https://github.com/openservicemesh/osm/blob/v0.8.2/pkg/service/types.go#L21-L25

Here is the definition of the new type we would like to use instead of K8sServiceAccount: https://github.com/openservicemesh/osm/blob/v0.8.2/pkg/identity/types.go#L5

Service identities can be abstracted without leaking kubernetes identity primitives to XDS code.

---

Related tasks:

• cleanup: identity: Remove GetSDSCSecretName() and GetCertificateCommonName() from ServiceIdentity identity: Remove GetSDSCSecretName() and GetCertificateCommonName() from ServiceIdentity #3182
• improvement: Mesh catalog functions matching ServiceAccount names should also match Kind field of the policy Mesh catalog functions matching ServiceAccount names should also match Kind field of the policy  #3173

[shashankram]

This issue needs further discussions and review. The motivation to create this issue is summarized below.

1. To not leak k8s identity primitives such as service accounts into the XDS code, and leverage the identity.ServiceIdentity type instead which also encodes the trust domain (cluster.local) in the identity
2. SMI's traffic access has a Kind attribute for the source and destination. It seems as though in the future there is room for using a different Kind (maybe ingress?) as a source, which would mean the ServiceAccount primitive might not determine the Kind for a service's identity
3. Using the fully qualified ServiceIdentity type (..) is cluster aware, where the trust domain is of the form cluster.local or cluster.foo. Since the mesh-catalog is responsible for aggregating information from the runtime platform (k8s), using the fully qualified ServiceIdentity type should be feasible.

This change might look trivial on the eye but isn't. There is a lot of refactoring that needs to be done to complete this task.
/cc @draychev

[draychev]

@shashankram I'd like to resolve this one step at a time. To me this is a baby step forward:

• Moving K8sServiceAccount from pkg/service to pkg/identity Moving K8sServiceAccount from pkg/service to pkg/identity #3152
  The goal of the PR is to move, but also prep the rest of the repo with the new import of the identity package.
  The following PRs would be smaller in size.

[shashankram]

@draychev thanks for taking this on.

One thing I wanted to clarify in this issue is the distinction between identity.ServiceIdentity and K8sServiceAccount. In the XDS verticals, identity.ServiceIdentity represents the fully qualified service identity including the trust domain, ex. svc-acc.namespace.cluster.local, whereas K8sServiceAccount does not include the trust domain.

So for multicluster environments where the trust domain for a service in another cluster could be of the form svc-acc.namespace.cluster.other, the fully qualified ServiceIdentity could provide additional metadata.

[draychev]

The plan so far:

1. Rename the pkg/catalog MeshCataloger interface functions: ...ServiceAccount -> ...ServiceIdentity:

• catalog: Rename ListAllowedInboundServiceAccounts to ListAllowedInboundServiceIdentities catalog: Rename ListAllowedInboundServiceAccounts to ListAllowedInboundServiceIdentities #3176
• catalog: Rename ListAllowedOutboundServiceAccounts to ListAllowedOutboundServiceIdentities catalog: Rename ListAllowedOutboundServiceAccounts to ListAllowedOutboundServiceIdentities #3178
• catalog: Rename ListServiceAccountsForService to ListServiceIdentitiesForService catalog: Rename ListServiceAccountsForService to ListServiceIdentitiesForService #3180

2. Add helpers to be able to switch from K8sServiceAccount to ServiceIdentity and reverse - some of these will be used short term to transition a step at a time. Others - for ServiceAccounts coming from K8s for instance - could stay long term:

• identity: Adding K8sServiceAccount.ToServiceIdentity() and ServiceIdentity.ToK8sServiceAccount() identity: Adding K8sServiceAccount.ToServiceIdentity() and ServiceIdentity.ToK8sServiceAccount() #3179

3. Migrate to ServiceIdentity:

• certificates: Envoy xDS Certs should have a ServiceIdentity in the CN; not ServiceAccount certificates: Envoy xDS Certs should have a ServiceIdentity in the CN; not ServiceAccount #3186
• identity: Remove hard-coded cluster.local trust domain and make flexible identity: Remove hard-coded cluster.local trust domain and make flexible #3187
• identity: Change (sophisticate) ServiceIdentity from a string to a struct{} so it can capture more context identity: Change (sophisticate) ServiceIdentity from a string to a struct{} so it can capture more context #3188

[shashankram]

All catalog APIs have been updated to use ServiceIdentity.