Add {Peer,Request}Authentication objects to Create Istio Config

[lucasponce]

This PR adds support to PeerAuthentication and RequestAuthentication objects in Create New IstioConfig.

Now together with AuthorizationPolicy, Kiali should be able to create all type of Security scenarios.

Requires kiali/kiali#2797

How to test:

• Try to create objects described in https://preliminary.istio.io/docs/tasks/security/authentication/authn-policy/
• Or try to add objects described in https://preliminary.istio.io/docs/reference/config/security/peer_authentication/ and https://preliminary.istio.io/docs/reference/config/security/request_authentication/

Fixes kiali/kiali#2797
Fixes kiali/kiali#2685
Fixes kiali/kiali#2694

[hhovsepy]

@lucasponce wdyt, from UX perspective, is't it better to disable Create button when Add Workload Selector and Add Port MTLS are checked but no values are given?

[lucasponce]

@lucasponce wdyt, from UX perspective, is't it better to disable Create button when Add Workload Selector and Add Port MTLS are checked but no values are given?

+1

[hhovsepy]

Please add regex check on RequestAuthentication name to disable the Create button if the name is wrong.

[xeviknal]

Creating a PeerAuthn, the Mutual TLS mode is always set to 'UNSET'. However, portLevelTLS mode works correctly.

[xeviknal]

I see in the RequestAuthentication that the fromHeaders field is an string input text whereas in the documentation says it is an object.

Is it intended to be like this? Perhaps implemented in a subsequent phase? If so, shouldn't we remove this option from the list?

[lucasponce]

@hhovsepy yes, you are right, I'm going to incorporate these validations, also extend them to
kiali/kiali#2694

[lucasponce]

@xeviknal

Is it intended to be like this? Perhaps implemented in a subsequent phase? If so, shouldn't we remove this option from the list?

Mmm in the form it's showed as "Header: value, Header2: value2", but when you create the yaml should be created as an object.

It's just visualization in the form is simpler just to match the pattern used by curl or similar.

I'll add helper text describing the format, and a validation there.

[lucasponce]

@hhovsepy @xeviknal I have addressed most of the validations and comments.

Basically I refactored the IstioConfigNewPage to have a common pattern.
This started with Sidecar and Gateways and now with more objects it was necessary to have some changes to proper add validations at different levels (common, like name, namespace) and specific of each object.

There is a pending work I'm reviewing, as Gateways have changed in Istio 1.6 and scenarios with https doesn't work well in the IstioConfig form and wizards, but I will probably send that in a separate PR to not increase this one without context.

Please, let me know if it works ok, @hhovsepy @xeviknal take care of all types, probably I may introduce some regression as the changes were important.

Thanks

[hhovsepy]

Tried all JWT rules :)
"forwardOriginalToken"'s value is ignored to add.
When all rule types are added, the empty dropdown with rule type is remaining, not critical but from UX perspective better to hide that line at all:

[lucasponce]

When all rule types are added, the empty dropdown with rule type is remaining, not critical but from UX perspective better to hide that line at all:

+1

It happens to other builders that use the same technique to remove available fields from a select.
So perhaps that change may apply to other places in AuthorizationPolicy as well.

[xeviknal]

I see that the jwks field disappears once you click to the '+' button.
I don't see that field either on @hhovsepy screenshot.

[lucasponce]

@xeviknal @hhovsepy I've addressed your comments, let me know how it looks.

[hhovsepy]

I can still see 2 problems:

1. "forwardOriginalToken"'s value is ignored to add.
2. "jwksUri" value causes error while creating. In logs: "admission webhook "validation.istio.io" denied the request: configuration is invalid: 1 error occurred:
   • URI scheme "" is not supported"

[xeviknal]

I am seeing this:

[lucasponce]

@hhovsepy @xeviknal you are right, I added the jwks into the JWT Rule Builder but there was a missing edge in the JWT List.

Also added uri validation for builder to only delegate on galley in more corner case scenarios.

[xeviknal]

Small comment added. LGTM besides that :)

[hhovsepy]

All my issues are fixed, thank @lucasponce .
Only small comment, when adding first JWT Rule, for the second one in the input it selects by default "audiences" rule and shows warning that "issuer" is required.

[lucasponce]

Only small comment, when adding first JWT Rule, for the second one in the input it selects by default "audiences" rule and shows warning that "issuer" is required.

That is expected, JWT Rule Builder can create 1 to many JWT Rules. Each JWT Rule should have an issuer. Any row in the JWT Rules List is a JWT Rule that must have an issuer field.

[hhovsepy]

Verified.

[hhovsepy]

Verified also fix of: kiali/kiali#2694