In my
previous blog post, I explained the upcoming architectural changes in API Gateway. Today, I would like to show you a preview of the forthcoming changes related to API Exposure topics and invite you to try out the Istio-based JWT handler in API Gateway APIRule.
Istio JWT alpha feature
Because the Istio-based JWT handler in API Gateway APIRule CR is an alpha feature, we cannot guarantee its stability yet. Final changes and API will be released with version v1 of APIRule, which will also contain updates related to OAuth2 flows. Follow the
epic issue to learn the details and keep up-to-date with the progress we make. If you have any feedback, feel free to reach out to us.
Configure the feature toggle
In order to play around with the Istio JWT handler in APIRule, you must configure API Gateway to start processing the JWT handler differently by switching it into Istio mode. Once you do it, all new and existing APIRules will be processed with new rules, and, as a consequence, . However, there's no need to be concerned - the workloads exposed and secured with JWT will still work as intended. The feature toggle is implemented not to disrupt the existing configuration. It gives you both a chance to get to know the upcoming changes and the possibility of switching back to the previous solution if needed.
Run the following command to configure API Gateway in such a way that it can process the JWT handler in Istio mode:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
name: api-gateway-config
namespace: kyma-system
data:
api-gateway-config: |
jwtHandler: "istio"
EOF
|
After applying the configuration, you must wait a few more minutes for API Gateway to retrieve it.
Expose and secure a workload with JWT
For the sake of simplicity, this tutorial uses
Istio httpbin as a workload. Follow the instructions from the
Create a workload tutorial to deploy it into your cluster. The Istio-based JWT handler introduces a hard requirement for a workload to be part of the Istio service mesh. Remember to make sure that your workload has the
sidecar injection enabled. To learn about the differences between Ory Oathkeeper and Istio JWT access strategies, read this
document.
Configure the scope, client ID, client secret, and the token URL in your application. To do it, use SAP Cloud Identity Services or an OIDC-complaint provider of your choice. Follow this tutorial to obtain a JWT token.
Export the Namespace in which you deployed your workload, the name of the Kyma domain to expose workloads, the issuer, and the JWKS URI. You can retrieve the JWKS URI from /.well-known/openid-configuration. Run:
export NAMESPACE={NAMESPACE_NAME}
export DOMAIN_TO_EXPOSE_WORKLOADS={KYMA_DOMAIN_NAME}
export ISSUER={YOUR_ISSUER}
export JWKS_URI={YOUR_JWKS_URI}
|
Run the following command to expose and secure your workload:
cat <<EOF | kubectl apply -f -
apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
name: istio-jwt
namespace: $NAMESPACE
spec:
gateway: kyma-system/kyma-gateway
host: httpbin.$DOMAIN_TO_EXPOSE_WORKLOADS
service:
name: httpbin
port: 8000
rules:
- path: /headers
methods: ["GET"]
accessStrategies:
- handler: jwt
config:
authentications:
- issuer: $ISSUER
jwksUri: $JWKS_URI
authorizations:
- requiredScopes: ["test"]
EOF
|
Having a JWT containing the scope test, you can access the httpbin headers endpoint:
If successful, the above command returns code 200 and a response containing the headers.
Conclusion
I want to encourage you to get acquainted with
Istio JWT specification and the
comparison of Ory Oathkeeper and Istio JWT access strategies as well as start experimenting with the new API. Subscribe to
SAP BTP, Kyma runtime blogs to be up-to-date with the upcoming changes. In case you have any concerns or feedback, leave a comment under this blog post or ask a question on the
SAP BTP, Kyma runtime community page.
