Add support for Linkerd to the intents-operator

[aerosouund]

Description

Create required linkerd resources (servers, httproutes, authpolicies, mtls authentications, network authentications) based on otterize client intents. An extra optional field has been added in the intent definition which is a port field. It extends the same pattern used in istio policies but applies it to each respective linkerd resource

References

• GitHub Issue/PR number addressed or fixed: https://github.com/otterize/intents-operator/issues/250

Testing

There is a built image in a public repo that you can deploy in a cluster with linkerd installed: aerosouund/intents-operator:0.1.34

Also include details of the environment this PR was developed in (language/platform/browser version):

• golang 1.21

• kubernetes 1.23 on EKS

• Linkerd 2.x

• [ ] This change adds test coverage for new/changed/fixed functionality

Checklist

• [ ] I have added documentation for new/changed functionality in this PR and in github.com/otterize/docs

[github-actions[bot]]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[aerosouund]

Over the upcoming period there's still some extra small functionality i want to add to the PR, but i've created it now to work on any large changes required at the same time

Including the following:

• don’t add the path in the name for the policies but validate if a policy should be created based on its targets, and add a random hash in the end of all policy names


• cleaner implementation for deletion, instead of iterating over each type

• move the creation of primary resources to the start of the loop instead of checking if it should be done for each intent

• add support for grpc and tcp probes if they also break when a http route is created

• create a generateHTTPRouteName method

[aquam8]

we'd be very interested in having support for Linkerd2 - then Otterize would really be a compelling solution for us as light user of EKS & Linkerd2 (mTLS, grpc load balancing but not leveraging authorization policies in linkerd). We use kubernetes network policies but we do not like it for the same reason you highlighted in your blog post. We're making a case towards dropping support for network policies all together (we are using Calico & aws vpc-cni) and we would be interesting in assessing how linkerd2/otterize could help with authorization policies on that side of the fence instead.

[orishoshan]

That's great to hear @aquam8! We've been working on a couple of infrastructure changes that are starting to come in and have blocked this PR from being merged, namely #409 and #439, so Linkerd support should be getting merged soon! Stay tuned :)

Would love to have you join us on Slack to hear more about your use case if possible: https://joinslack.otterize.com

[aquam8]

Could this work be revised now that the dependent PRs have been merged, thank you!

[aerosouund]

@evyatarmeged @orishoshan PR rebased and cleaned, please review and let me know