Open orishoshan opened 1 year ago
@aerosouund has taken this issue :)
For this example ClientIntents:
apiVersion: k8s.otterize.com/v1alpha3
kind: ClientIntents
metadata:
name: client
namespace: otterize-tutorial-istio
spec:
service:
name: client
calls:
- name: nginx
type: http
HTTPResources:
- path: /client-path
methods: [ GET ]
Server
resource for nginx
if it wasn't already created, as well as a HTTPRoute
for the HTTPResources
part (if there are any).MeshTLSAuthentication
resource for client
if it wasn't already created. For each client, create a separate MeshTLSAuthentication
resource. I recommend using the name of the client in the name of the resource, such as meshtls-client1
, meshtls-client2
, and so on, to make it easy to find the resources when you need to update them or check if they already exist.AuthorizationPolicy
resource that requires the MeshTLSAuthentication
or Server
.As we discussed on Zoom, start with the create
flow for ClientIntents
and then move on to edit and delete. To understand the edit flow better, after creating a MeshTLS resource, scale down the intents operator to 0, then edit the ClientIntents so that the client
is client2
, and you should see two MeshTLS
resources. In that situation the intents-operator needs to be able to detect that the first resource is now orphaned and delete it.
Sounds good @aerosouund?
Sounds perfect, will move on with implementing this!
The intents operator supports reconciling ClientIntents into Istio authorization policies.
Proposal: Add support for Linkerd authorization policies, keeping with the same style.