Issue implementing API Key/Quota validation with the Apigee Istio adapter
I've had an issue with the implementation of the API key/quota validation using the apigee-istio adapter.
The authorization is configured in the default definitions.yaml file provided in the adapter installation directory:
# instance configuration for template 'apigee.authorization'
apiVersion: config.istio.io/v1alpha2
kind: authorization
metadata:
name: apigee
namespace: istio-system
spec:
subject:
user: ""
groups: ""
properties:
api_key: request.api_key | request.headers["x-api-key"] | ""
json_claims: request.auth.raw_claims | ""
action:
namespace: destination.namespace | "default"
service: api.service | destination.service.host | ""
path: api.operation | request.path | ""
method: request.method | ""
And the following default rule.yaml file defines the rule:
# Defines rules to apply the Apigee mixer adapter to requests.
# In the rule below, we apply Apigee authorization and analytics
# as defined in the apigee-handler (handler.yaml) to all intra-mesh
# requests.
---
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: apigee-rule
namespace: istio-system
spec:
match: context.reporter.kind == "inbound" && destination.namespace == "default"
actions:
- handler: apigee-handler.apigee.istio-system
instances:
- apigee.authorization
- apigee.analytics
I have mutual TLS enabled in my Istio installation, and the rule is preventing my services from communicating with each other, specifically my services cannot access my mongo db service that is running on the same cluster in the same namespace. I have implemented the default JWT authentication with no issues, but the apikey authentication causes this issue.
In the configuration, I feel that the match: context.reporter.kind == "inbound" specification should only target inbound services, and not communication between services. Still, it seems that the intra-mesh communication is being affected. Is there a way to configure this rule or otherwise implement this feature while using mTLS in the mesh?
Best Answer
Yes, the attribute names can be confusing. The "context.reporter.kind" is really just filtering between kinds of Mixer traffic from the proxies, so it's not useful in your context. To limit the rule to just applying at ingress, you'll need a rule that looks like this:
source.labels["istio"] == "ingressgateway"
Thank you, from my initial testing this condition has made the implementation work as intended.
In the match, Like this?
# Defines rules to apply the Apigee mixer adapter to requests.
# In the rule below, we apply Apigee authorization and analytics
# as defined in the apigee-handler (handler.yaml) to all intra-mesh
# requests.
---
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: apigee-rule
namespace: istio-system
spec:
match: source.labels["istio"] == "ingressgateway"
actions:
- handler: apigee-handler.apigee.istio-system
instances:
- apigee.authorization
- apigee.analytics
Yes, in the match, I left the other default conditions in for my implementation like this:
match: context.reporter.kind == "inbound" && destination.namespace == "default" && source.labels["istio"] == "ingressgateway"
