External Authorization
This task shows you how to set up an Istio authorization policy using a new value for the action field, CUSTOM
,
to delegate the access control to an external authorization system. This can be used to integrate with OPA authorization6,
oauth2-proxy
7, your own custom external authorization server and more.
Before you begin
Before you begin this task, do the following:
Read the Istio authorization concepts.
Follow the Istio installation guide8 to install Istio.
Deploy test workloads:
This task uses two workloads,
httpbin
andsleep
, both deployed in namespacefoo
. Both workloads run with an Envoy proxy sidecar. Deploy thefoo
namespace and workloads with the following command:Verify that
sleep
can accesshttpbin
with the following command:
Deploy the external authorizer
First, you need to deploy the external authorizer. For this, you will simply deploy the sample external authorizer in a standalone pod in the mesh.
Run the following command to deploy the sample external authorizer:
Verify the sample external authorizer is up and running:
Alternatively, you can also deploy the external authorizer as a separate container in the same pod of the application that needs the external authorization or even deploy it outside of the mesh. In either case, you will also need to create a service entry resource to register the service to the mesh and make sure it is accessible to the proxy.
The following is an example service entry for an external authorizer deployed in a separate container in the same pod of the application that needs the external authorization.
Define the external authorizer
In order to use the CUSTOM
action in the authorization policy, you must define the external authorizer that is allowed to be
used in the mesh. This is currently defined in the extension provider11
in the mesh config.
Currently, the only supported extension provider type is the Envoy ext_authz
12 provider.
The external authorizer must implement the corresponding Envoy ext_authz
check API.
In this task, you will use a sample external authorizer13 which
allows requests with the header x-ext-authz: allow
.
Edit the mesh config with the following command:
In the editor, add the extension provider definitions shown below:
The following content defines two external providers
sample-ext-authz-grpc
andsample-ext-authz-http
using the same serviceext-authz.foo.svc.cluster.local
. The service implements both the HTTP and gRPC check API as defined by the Envoyext_authz
filter. You will deploy the service in the following step.Alternatively, you can modify the extension provider to control the behavior of the
ext_authz
filter for things like what headers to send to the external authorizer, what headers to send to the application backend, the status to return on error and more. For example, the following defines an extension provider that can be used with theoauth2-proxy
7:
Enable with external authorization
The external authorizer is now ready to be used by the authorization policy.
Enable the external authorization with the following command:
The following command applies an authorization policy with the
CUSTOM
action value for thehttpbin
workload. The policy enables the external authorization for requests to path/headers
using the external authorizer defined bysample-ext-authz-grpc
.At runtime, requests to path
/headers
of thehttpbin
workload will be paused by theext_authz
filter, and a check request will be sent to the external authorizer to decide whether the request should be allowed or denied.Verify a request to path
/headers
with headerx-ext-authz: deny
is denied by the sampleext_authz
server:Verify a request to path
/headers
with headerx-ext-authz: allow
is allowed by the sampleext_authz
server:Verify a request to path
/ip
is allowed and does not trigger the external authorization:Check the log of the sample
ext_authz
server to confirm it was called twice (for the two requests). The first one was allowed and the second one was denied:You can also tell from the log that mTLS is enabled for the connection between the
ext-authz
filter and the sampleext-authz
server because the source principal is populated with the valuespiffe://cluster.local/ns/foo/sa/sleep
.You can now apply another authorization policy for the sample
ext-authz
server to control who is allowed to access it.
Clean up
Remove the namespace
foo
from your configuration:Remove the extension provider definition from the mesh config.
Performance expectations
See performance benchmarking14.