Question: opa-envoy-plugin - Istio Version 1.7?

[briannd81]

Our team is contemplating on whether to deploy OPA as a plugin or standalone.

Link to plugin: https://github.com/open-policy-agent/opa-envoy-plugin

Clearly, the plugin has many benefits over the standalone deployment, such as:

Performance

• scales with service as the plugin is deployed as a sidecar

• avoid network hop

Security

• OPA can only be accessed by envoy via localhost interface

Here are our concerns:

1. Istio Compatibility

• does it support the latest Istio?

2. Documentation

• there aren't that many blogs or documentation other than the github readme. If we run into production issues we won't be able to resolve.

3. Development and Support

• is this plugin being actively developed and improved?

Any insights into these concerns would be highly appreciated.

[patrick-east]

does it support the latest Istio?

I believe so, although I don't see where we document compatibility for the plugin. @ashutosh-narkar can you confirm?

there aren't that many blogs or documentation other than the github readme. If we run into production issues we won't be able to resolve.

Keep in mind that the envoy plugin is a pretty thin wrapper around OPA, for the majority of usage any of the OPA docs/blogs/etc are relevant.

Generally when users need help or have questions the best venue is on Github or the OPA community slack. There are also companies which offer commercial support for OPA https://www.openpolicyagent.org/support

is this plugin being actively developed and improved?

Yes. The project is maintained by the OPA team, and receives updates as needed.

[ashutosh-narkar]

does it support the latest Istio?

Yes it does. It supports Istio v1.5.0 or later.

[briannd81]

Thanks for the responses. @ashutosh-narkar @patrick-east

We have the following business cases. Can we use the plugin approach for either or both?

1. Externalize authorization for service endpoints
2. Inject pod security context when new pods are launched

[ashutosh-narkar]

Externalize authorization for service endpoints

Yes it will work for this use-case. Whenever Envoy gets a request, it will call OPA for an authz decision.

Inject pod security context when new pods are launched

Is the idea here to inject a securityContext field in the Pod specification ? If yes, then you would have to use OPA as a mutating admission controller to achieve that.

[briannd81]

Externalize authorization for service endpoints

Yes it will work for this use-case. Whenever Envoy gets a request, it will call OPA for an authz decision.

Inject pod security context when new pods are launched

Is the idea here to inject a securityContext field in the Pod specification ? If yes, then you would have to use OPA as a mutating admission controller to achieve that.

Yes. So the sidecar deployment would not work here correct? Is there another plugin to ease the process of deploying OPA as a mutating admission controller?

[ashutosh-narkar]

These are 2 different use-cases: 1) OPA as a mutating admission controller to inject a field in the Pod spec and 2) opa-envoy-plugin to make authorization decisions in the request path.

For 1) See this tutorial for how you can use OPA as an admission controller. See this example for a reference to use OPA as a mutating admission controller.

For 2) Your application pods will include an OPA sidecar along with an Envoy sidecar. When Envoy receives API requests destined for your microservice, it checks with OPA to decide if the request should be allowed. Evaluating policies locally with Envoy will be beneficial from a performance perspective and introduce low latency in the request path.

[briannd81]

These are 2 different use-cases: 1) OPA as a mutating admission controller to inject a field in the Pod spec and 2) opa-envoy-plugin to make authorization decisions in the request path.

For 1) See this tutorial for how you can use OPA as an admission controller. See this example for a reference to use OPA as a mutating admission controller.

For 2) Your application pods will include an OPA sidecar along with an Envoy sidecar. When Envoy receives API requests destined for your microservice, it checks with OPA to decide if the request should be allowed. Evaluating policies locally with Envoy will be beneficial from a performance perspective and introduce low latency in the request path.

If we don't want to use the plugin for opa sidecar, is there an alternative if we want to do ext authz? Is the plugin stable for production?

[ashutosh-narkar]

Yes we release new versions of the opa-envoy-plugin whenever a new OPA version is released. We actively maintain the plugin and make updates, fix bugs etc. as necessary.

[briannd81]

What are the major differences between the 2 solutions below? Can either solution be used for running opa as a sidecar?

1. https://github.com/open-policy-agent/opa-envoy-plugin/blob/master/quick_start.yaml

2. https://github.com/open-policy-agent/opa-envoy-plugin/blob/master/examples/istio/quick_start.yaml#L221

[ashutosh-narkar]

What are the major differences between the 2 solutions below? Can either solution be used for running opa as a sidecar?

1. https://github.com/open-policy-agent/opa-envoy-plugin/blob/master/quick_start.yaml
2. https://github.com/open-policy-agent/opa-envoy-plugin/blob/master/examples/istio/quick_start.yaml#L221

Both the above solutions use the opa-envoy-plugin sidecar to make authz decisions in the request path. The difference is in 1) the opa-envoy-plugin sidecar is manually included in the pod via the deployment manifest. In 2) the opa-envoy-plugin sidecar is automatically injected into pods in namespaces labelled with opa-istio-injection=enabled. The injection is performed by OPA deployed as a mutating admission controller (not opa-envoy-plugin) in its own namespace and its not deployed as a sidecar.

If you're using Istio use 2) and if you are using vanilla Envoy use 1). Both use Envoy's external authorization filter and opa-envoy-plugin deployed as a sidecar to making authz decisions.

[briannd81]

Thanks for the explanation. Is there any legitimate use case for using #2 with Istio?

[ashutosh-narkar]

The opa-envoy plugin extends OPA with a gRPC server that implements the Envoy External Authorization API. 1) shows how to use it with vanilla Envoy. 2) shows how you can use it with Istio Proxy (a wrapper around Envoy). In the future we will have other examples of how to use the opa-envoy plugin with other Envoy-based services meshes like Kuma, Open Service Mesh etc.

[briannd81]

I got it backwards. My previous question was supposed to be this: is there any legitimate reason to use #1 with Istio. To me, that would not make sense because essentially we'll have 2 envoys since Istio already have 1 envoy. I'm trying to convince someone that this is an anti-pattern but want to be sure my understanding is correct. Please confirm.

[ashutosh-narkar]

To me, that would not make sense because essentially we'll have 2 envoys since Istio already have 1 envoy

Why would we have two Envoys ? Remember the opa-envoy plugin is not Envoy itself. It simply implements Envoy's External Authorization API. So instead of having an Envoy container and application container in your pod, you now have an Envoy container, application container and the opa-envoy-plugin container.

Istio Proxy (aka Envoy) still does the proxying, application container implements the business logic and opa-envoy-plugin provides fine-grained policy decisions. There is still only ONE Envoy in pod.

[briannd81]

If my environment already have Istio installed, what issues are we going to encounter if we use the plugin in #1 (without mutating wehook). Is it even going to work? I know #2 makes more sense, but I'm trying to convince why #1 isn't.

[ashutosh-narkar]

1. is a manual way of adding the plugin to an application pod. 2) is more automatic and so if you deploy a new app, the admission controller (in this case OPA) will automatically inject the plugin in your pod. Istio supports both manual and automatic sidecar injection, so it's up to you what route your prefer.

[patrick-east]

Looks like the questsions are all answered, going to close this issue for now. Feel free to re-open if more info is needed 😄