Move Istio from EnvoyFilter to AuthorizationPolicy

[howardjohn]

Currently OPAs Istio docs are using EnvoyFilter which is fragile/alpha/not recommended where possible. Authorization Policy has first class support for ext_authz now: https://istio.io/latest/docs/tasks/security/authorization/authz-custom/.

The different between the two seems to be usage of google_grpc in the EnvoyFilter:

            grpc_service:
              # NOTE(tsandall): when this was tested with the envoy_grpc client the gRPC
              # server was receiving check requests over HTTP 1.1. The gRPC server in
              # OPA-Istio would immediately close the connection and log that a bogus
              # preamble was sent by the client (it expected HTTP 2). Switching to the
              # google_grpc client resolved this issue.
              google_grpc:
                target_uri: 127.0.0.1:9191
                stat_prefix: "ext_authz"

However, I think this is just a misconfiguration of Istio likely, missing the declaration of the service as HTTP. See https://istio.io/latest/docs/tasks/security/authorization/authz-custom/#deploy-the-external-authorizer.

I think it would be great to move this over, and we (Istio team; I am a maintainer) are happy to help.

[ashutosh-narkar]

@howardjohn thanks so much for opening this issue and offering to help. Would you be able to swap out the EnvoyFilter from this example manifest and submit a PR? Also we'd need to verify the steps documented in this tutorial still work after the update. Please let us know if you need any help.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.

[tjons]

@ashutosh-narkar I can take this over... I work a lot with istio and am familiar with the changes required here. Would be nice to get these docs updated so folks are using latest APIs

[ashutosh-narkar]

Sounds good. Thanks @tjons!

[tjons]

@ashutosh-narkar this will require a bit of a rewrite of the tutorial to move to using AuthorizationPolicy instead of EnvoyFilter. AuthorizationPolicy is designed to be used with a provider registered in the mesh config that authorization requests are delegated to, instead of injecting an additional sidecar on each Auth-required service. I'm happy to undertake that, but if you want to demonstrate the ability to use the opa-envoy-plugin in this tutorial that will still require an EnvoyFilter.

@howardjohn can you confirm my understanding is correct? If we want to use an AuthorizationPolicy here we will need to deploy OPA as a service and register it in the MeshConfig, not as an additional injected sidecar into each OPA-enabled pod.

[tjons]

Here's a rough sketch of how this would work with `AuthorizationPolicy`

[anderseknert]

That seems like quite a deviation from how OPA — or any authorization service in a zero trust environment — normally operates. Maybe I'm reading this wrong, but is the suggestion here to go from OPA making authorization decisions for each service to OPA being used as a form of centalized gateway authorizer?

[howardjohn]

No, you can do either approach. The API need not determine the deployment pattern.

This issue is about moving from an unstable API to a stable one. There should be no architectural changes.

You just need to make the service point to 127.0.0.1

[anderseknert]

Thanks @howardjohn, that's reassuring. I probably misread, or misunderstood @tjons then.

[ashutosh-narkar]

There should be no architectural changes.

Just to clarify we can still deploy OPA as sidecar next to each service if we use AuthorizationPolicy?

[tjons]

@howardjohn Are you suggesting that the service registered in the meshconfig point to 127.0.0.1 and we use that to route traffic to the injected OPA sidecar in each pod that's selected by the authorizationpolicy? this tutorial is based around injecting the opa-envoy-plugin as a sidecar to each istio-injected service.

I think it probably makes sense to have another accompanying tutorial that shows using OPA as a cluster-wide authorizer with a single deployment too, but that can be another issue.

[howardjohn]

Exactly. The final output architecture/config should be the same, just using a supported API (AuthorizationPolicy) instead of an unstable one (EnvoyFilter)

[tjons]

cool, thanks for your input @howardjohn. @ashutosh-narkar @anderseknert I'll make and push the changes today.