API gateways play a vital role while exposing microservices. They are an additional hop in the network that the incoming request must go through in order to communicate with the services. An API gateway does routing, composition, protocol translation, and user policy enforcement after it receives a request from client and then reverse proxies it to the appropriate underlying API. As the API gateways are capable of doing the above-mentioned tasks, they can be also configured to send the incoming client requests to an external third-party authorization (authz) server. The fate of the incoming request then depends upon the response from this external authz server to the gateway. This is exactly where Open Policy Agent (OPA) comes into the picture. There are many open source Kubernetes native API gateways out there like Contour, Kong Gateway, Traefik, Gloo, etc.. In this article, we will be exploring the Emissary Ingress. Let's dive deep and start understanding more bit about [Emissary Ingress](https://github.com/emissary-ingress/emissary). ## What's Emissary Ingress? Emissary Ingress was earlier known as Ambassador API gateway, it is an open source Kubernetes native API gateway and is currently a [CNCF Incubation Project](https://www.cncf.io/projects/emissary-ingress/). Like many other Kubernetes gateways, Emissary has also been built to work with Envoy Proxy. It is deployed as complete stateless architecture and supports multiple plugins such as traditional SSO authentication protocols (e.g.: OAuth, OpenID Connect), rate limiting, logging, and tracing service. Emissary utilizes its [ExtAuth protocol](https://www.getambassador.io/docs/emissary/latest/topics/running/services/ext_authz/) in [AuthService](https://www.getambassador.io/docs/emissary/latest/topics/running/services/auth-service/) resource to configure the authentication and authorization for incoming requests. `ExtAuth` supports two protocols: gRPC and plain HTTP. For gRPC interface, the external service must implement Envoy's [external_auth.proto](https://github.com/emissary-ingress/emissary/blob/master/api/envoy/service/auth/v2/external_auth.proto). ## OPA Open Policy Agent is a well-known general-purpose policy engine and has emerged as a policy enforcer across the stacks be it API gateways, service meshes, Kubernetes, microservice, CICD, or IAC. OPA decouples decision making from policy enforcement such that whenever your software needs to make a decision regarding the incoming requests, it queries OPA. [OPA-Envoy](https://github.com/open-policy-agent/opa-envoy-plugin) extends OPA with a gRPC server that implements the Envoy [External Authorization API](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter), thus making itself compatible to be as an external authz server to Emissary. ## Integrating Emissary Ingress with OPA ![Emissary OPA](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a6qxlbqfc6jjahyavq0v.png) The above figure shows highlevel architecture of Emissary and OPA integration. When incoming request from client reaches Emissary, it sends an authorization request to OPA which contains input JSON. OPA evaluates this JSON against the Rego policies provided to it and responds to Emissary, if this result JSON from OPA has `allow` as `true` then only the client request is further routed to API or else the request is denied by Emissary and never reaches the API. Now, we will be installing Emissary Ingress and integrate it with OPA for external authorization. ### Getting Started First, we will be needing to start a Minikube cluster. If you don't have Minikube, you can install it from [here](https://minikube.sigs.k8s.io/docs/start/). ```shell minikube start ``` Install the Emissary Ingress to the minikube through Helm. ```shell # Add the Repo: helm repo add datawire https://app.getambassador.io helm repo update # Create Namespace and Install: kubectl create namespace emissary && \ kubectl apply -f https://app.getambassador.io/yaml/emissary/2.2.2/emissary-crds.yaml kubectl wait --timeout=90s --for=condition=available deployment emissary-apiext -n emissary-system helm install emissary-ingress --namespace emissary datawire/emissary-ingress && \ kubectl -n emissary wait --for condition=available --timeout=90s deploy -lapp.kubernetes.io/instance=emissary-ingress ``` Or go to [Emissary Ingress Documentation](https://www.getambassador.io/docs/emissary/latest/tutorials/getting-started/) to install it through Kubernetes YAMLs. ### Configuring the routing for demo application Different gateways have their own set of configurations for exposing a service. In Emissary, we need to configure the routing through Mappings and Listeners. Mapping resource simply tells Emissary which service to redirect the incoming request to. It is highly configurable like `Ingress`. You can learn more about Mapping resource on [Introduction to the Mapping resource](https://www.getambassador.io/docs/emissary/latest/topics/using/intro-mappings/) page. We will create a simple `Mapping` resource which will redirect all the incoming requests to our demo application's service that is `demo-svc`. ```shell cat <

tayyabjamadar

How do you Integrate Emissary Ingress with OPA

Join Our Newsletter. No Spam, Only the good stuff.