-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ADR] API proposal for configuration of External Authorizer based authorization in API Rule #938
Comments
I have a question about a use case I am currently on. I want to add an external authorizer for geo-blocking (prevent access from embargoed countries). Such an authorizer should be triggered on all paths and methods. Can your API proposal model this use case? |
In this case you could use the following selector: path: "/.*"
methods: ["GET", "HEAD", "POST", "PUT", "DELETE", "CONNECT", "OPTIONS", "TRACE", "PATCH"]
accessStrategy:
extAuth:
name: geo-blocker Geo-blocking could be a part of the external authoriser logic (with the name of |
Can you confirm that with such configuration request to header path will execute both authorizers (geo-blocking and oauth2-proxy)?
|
Updated the ADR -
|
Thanks for update. Looks good to me! |
API proposal for configuration of External Authorizer based authorization in APIRules
Status
Proposed: 13.03.2024
Accepted: 27.03.2024
Details
We are going to introduce a new handler for APIRules that allows configuring External Authorizer for services exposed by the user.
The new access strategy will be called
extAuth
, which follows the camel case naming convention used for previous strategies. Theno_auth
access strategy will also change its name tonoAuth
in the future.Considerations
Should we support combining the
extAuth
andjwt
access strategies?The Authorization Policy that enables External Authorizer uses
action: CUSTOM
. This allows the External Authorizer handler to be used alongside other handlers, especially Istio-based JWT. The reason such a configuration is possible is because theCUSTOM
actions are evaluated independently, as described in the Istio Authorization Policy documentation. By taking advantage of this, the customer could have a setup that performs both authentication with an OAuth2 Authorization code flow as well as authorization based on the presented JWT.For example, it is possible to use the following configuration:
AuthorizationPolicy
enabling External Authorizer:AuthorizationPolicy
restricting the access on a claim-based strategy:RequestAuthentication
ensuring that Istio recognizes the issuer:Decision
We decided to enforce that the user must use one and only one accessStrategy per every entry in spec.rules. Therefore, we don't support combining both
extAuth
andjwt
access strategies.Instead, we would like to enable configuration within the
extAuth
strategy scope and allow the creation of anALLOW
AuthorizationPolicy based on that configuration.As a result, the proposed API would look as follows:
Should we support multiple External Authorizers?
We must consider whether a configuration that uses multiple external authorizers on one path is valuable. Technically, such configuration would be possible, as all
CUSTOM
policies must result in theallow
response for the request to be allowed.Decision
We decided to support multiple External Authorizers. Since there are some useful configurations that our users might want to have.
API Proposal
We have discussed how the API would be structured to support future versions, specifically
v1beta2/v1
. We decided that accessStrategy will hold a single entry, eitherextAuth
,jwt
, ornoAuth
. The user must define only one access strategy in every rule of the spec.rules field.See the following sample, which uses the proposed API:
The text was updated successfully, but these errors were encountered: