Better External Authorization
AuthorizationPolicy now supports CUSTOM action to delegate the authorization to external system.
Background
Istio’s authorization policy provides access control for services in the mesh. It is fast, powerful and a widely used
feature. We have made continuous improvements to make policy more flexible since its first release in Istio 1.4, including
the DENY
action, exclusion semantics,
X-Forwarded-For
header support, nested JWT claim support
and more. These features improve the flexibility of the authorization policy, but there are still many use cases that
cannot be supported with this model, for example:
You have your own in-house authorization system that cannot be easily migrated to, or cannot be easily replaced by, the authorization policy.
You want to integrate with a 3rd-party solution (e.g. Open Policy Agent or
oauth2
proxy) which may require use of the low-level Envoy configuration APIs in Istio, or may not be possible at all.Authorization policy lacks necessary semantics for your use case.
Solution
In Istio 1.9, we have implemented extensibility into authorization policy by introducing a CUSTOM
action,
which allows you to delegate the access control decision to an external authorization service.
The CUSTOM
action allows you to integrate Istio with an external authorization system that implements its own custom
authorization logic. The following diagram shows the high level architecture of this integration:
At configuration time, the mesh admin configures an authorization policy with a CUSTOM
action to enable the
external authorization on a proxy (either gateway or sidecar). The admin should verify the external auth service is up
and running.
At runtime,
A request is intercepted by the proxy, and the proxy will send check requests to the external auth service, as configured by the user in the authorization policy.
The external auth service will make the decision whether to allow it or not.
If allowed, the request will continue and will be enforced by any local authorization defined by
ALLOW
/DENY
action.If denied, the request will be rejected immediately.
Let’s look at an example authorization policy with the CUSTOM
action:
It refers to a provider called my-ext-authz-service
which is defined in the mesh config:
The authorization policy of CUSTOM
action
enables the external authorization in runtime, it could be configured to trigger the external authorization conditionally
based on the request using the same rule that you have already been using with other actions.
The external authorization service is currently defined in the meshconfig
API
and referred to by its name. It could be deployed in the mesh with or without proxy. If with the proxy, you could
further use PeerAuthentication
to enable mTLS between the proxy and your external authorization service.
The CUSTOM
action is currently in the experimental stage; the API might change in a non-backward compatible way based on user feedback.
The authorization policy rules currently don’t support authentication fields (e.g. source principal or JWT claim) when used with the
CUSTOM
action. Only one provider is allowed for a given workload, but you can still use different providers on different workloads.
For more information, please see the Better External Authorization design doc.
Example with OPA
In this section, we will demonstrate using the CUSTOM
action with the Open Policy Agent as the external authorizer on
the ingress gateway. We will conditionally enable the external authorization on all paths except /ip
.
You can also refer to the external authorization task for a more
basic introduction that uses a sample ext-authz
server.
Create the example OPA policy
Run the following command create an OPA policy that allows the request if the prefix of the path is matched with the claim “path” (base64 encoded) in the JWT token:
Deploy httpbin and OPA
Enable the sidecar injection:
Run the following command to deploy the example application httpbin and OPA. The OPA could be deployed either as a separate container in the httpbin pod or completely in a separate pod:
Deploy the httpbin as well:
Define external authorizer
Run the following command to edit the meshconfig
:
Add the following extensionProviders
to the meshconfig
:
Create an AuthorizationPolicy with a CUSTOM action
Run the following command to create the authorization policy that enables the external authorization on all paths
except /ip
:
Test the OPA policy
Create a client pod to send the request:
Use a test JWT token signed by the OPA:
The test JWT token has the following claims:
The
path
claim has valueL2hlYWRlcnM=
which is the base64 encode of/headers
.Send a request to path
/headers
without a token. This should be rejected with 403 because there is no JWT token:Send a request to path
/get
with a valid token. This should be rejected with 403 because the path/get
is not matched with the token/headers
:Send a request to path
/headers
with valid token. This should be allowed with 200 because the path is matched with the token:Send request to path
/ip
without token. This should be allowed with 200 because the path/ip
is excluded from authorization:Check the proxy and OPA logs to confirm the result.
Summary
In Istio 1.9, the CUSTOM
action in the authorization policy allows you to easily integrate Istio with any external
authorization system with the following benefits:
First-class support in the authorization policy API
Ease of usage: define the external authorizer simply with a URL and enable with the authorization policy, no more hassle with the
EnvoyFilter
APIConditional triggering, allowing improved performance
Support for various deployment type of the external authorizer:
A normal service and pod with or without proxy
Inside the workload pod as a separate container
Outside the mesh
We’re working to promote this feature to a more stable stage in following versions and welcome your feedback at discuss.istio.io.
Acknowledgements
Thanks to Craig Box
, Christian Posta
and Limin Wang
for reviewing drafts of this blog.