"no_auth" handler

[strekm]

Description

As a follow up of https://github.com/kyma-project/api-gateway/issues/462 introduce Istio based handler exposing workload given path and given methods.

PR:

• https://github.com/kyma-project/api-gateway/pull/860

TODO:

• [x] Decide on name of the new handler
  • Since nobody has spoken out against it, we will use no_auth
• [x] Add validation of methods in APIRule to only allow valid HTTP methods
• [x] Extend istio-jwt processing to support new handler.
• [x] For istio-jwt add methods restriction to VirtualService for new handler and existing noop, jwt and oauth2_introspection handlers.
• [x] Extend ory processing to support new handler. Only new handler will have restriction for methods in VirtualService.
• [x] Add handler to UI and make it the new default instead of allow
• [x] Add documentation for new handler

ACs:

• [x] new handler introduced
• [x] validation
• [x] methods attribute is mandatory array with at least one item
• [x] handler UI
• [x] integration tests (including negative scenarios)
• [x] documentation

Reasons

DoD:

• [x] Provide unit and integration tests.
• [x] Provide documentation.
• [x] Verify if the solution works for both open-source Kyma and SAP BTP, Kyma runtime.
• [x] Verify that your contributions don't decrease code coverage. If they do, explain why this is the case.
  • Added tests for untested packages, but the coverage is calculated wrong.
• [x] Add release notes.

Attachments

[triffer]

Most of our access strategy handlers are Oathkeeper Authenticators (noop, jwt, oauth2_introspection, ...). For these handlers it's clear that its about so authn. The "allow" handler is ignoring authn and just expose the path with all methods.

The new handler would work in the same way by ignoring authn, but restrict access to methods. The proposed name "allow_methods" is confusing as long as the "allow" handler exists, because it's not extending the scope of allow, but limiting it. "allow" already allow all methods, but "allow_methods" restricts method exposure. That's why the name is confusing in my opinion.

I'd follow the initial idea of naming the handlers after authentication scope. The equality of "allow" would be, that this path and methods require no authentication, that's why I suggest to call the handler no_auth.

For now allow and no_auth are also very similar and can cause confusion, but the same applies to allow and allow_methods. Once we remove allow, in my opinion no_auth would be better fit into our API than allow_ methods.