OAuth2 via OIDC
OAuth2 ensures that your web application (upstream) doesn't get requests which are not authenticated and authorized. It effectively helps to protect your web application.
This is for web applications authentication. If you want to secure your APIs you can use JWT authentication
Kusk implements the OpenID Connect (OIDC) layer which ensures you can choose any OAuth2 provider and Kusk will support it as long as the OAuth2 provider also supports OIDC.
Kusk makes it easy to configure OAuth2, using the
auth option in you
The OAuth2 feature is currently under active development. See upstream issues.
We'll go through step-by-step of configuring OAuth2. In this example we'll be using Auth0 as OAuth2 provider.
1. Configuring Auth0
- Signup for an account at Auth0.
- Create an Auth0 Application
- Configure the following Auth0 Application fields: (KUSK_IP is the IP of the Kusk's LoadBalancer, you can obtain it by running
1. Allowed Callback URLs (e.g. `http://**KUSK_IP**/oauth2/callback`)
2. Allowed Logout URLs (e.g. `http://**KUSK_IP**/oauth2/signout`)
- Take note of the credentials as we will need this later on:
2. Deploy your web application to Kusk
Deploy your web application to Kubernetes or use our example application:
kubectl create deployment oauth-app --image=kubeshop/kusk-oauth-app-example:v1.0.0
kubectl expose deployment oauth-app --name oauth-app-svc --port=3000
3. Expose the web-application with OAuth using Kusk
The example below ensures the whole API is protected via OAuth2, and that the upstream
oauth-app-svc can be only accessed when authenticated and authorized.
You are required to change:
auth_scopes: Strictly speaking this is not required but we strongly suggest entering
openidfor testing purposes
After that, expose the web-application with Kusk by running:
kubectl apply -f static-route.yaml
4. Update EnvoyFleet ConfigMap
We need to include to
client_secret to Envoy's
ConfigMap, by running
kubectl edit -n kusk-system configmaps kusk-gateway-envoy-fleet
And then update the field
inline_string replacing it with the
client_secret obtained from Auth0.
- name: token
inline_string: "<stub_token_secret>" # <- replace with "CLIENT_SECRET"
Finally, you should save the configuration and the changes will be applied.
5. Restart Envoy Fleet
As we currently have upstream issues with Envoy waiting to be fixed, the temporal solution is to restart Envoy manually (this only needs to be done once):
- Port-Forward into Envoy's control plane:
kubectl port-forward --namespace kusk-system deployment/kusk-gateway-envoy-fleet 19000:19000
- Restart Envoy by making a POST request to
curl -X POST 'http://localhost:19000/quitquitquit'
- Wait until the changes to be propogated, this could take a while. To know if the Envoy has restarted, check if the Envoy container has restarted
kubectl get pods -w -n kusk-system --selector=app.kubernetes.io/instance=kusk-gateway-envoy-fleet
NAME READY STATUS RESTARTS AGE
kusk-gateway-envoy-fleet-6f9ff68bcd-jxlwk 1/1 Running 1 (30s ago) 1h
6. Test using the browser
You're all set now, test your OAuth2 implementation through the browser by visiting Kusk's LoadBalancer. Get the URL with:
Now visit the address in the browser and you'll see that you web application is now using Auth0's OAuth page:
Certain OAuth2 features are blocked/constrained by upstream issues. Please see:
- Segmentation Fault after `assert failure: false. Details: attempted to add shared target SdsApi <NAME_OF_SECRET> to initialized init manager Server.
So the implementation is constrained by these issues, which should be fixed by January 2023.