Kusk: Configuring your Ingress Controller for CORS with OpenAPI
CORS — Cross-Origin Resource Sharing — is a mechanism that allows browser and server to communicate and establish a set of security settings that tell a browser which origins scripts may be loaded from and what it can talk to.
Not only having a properly configured CORS is crucial to have a functioning web application talking to an APIs, it’s also very important to thoroughly review allowed CORS origins from a security perspective to disallow third parties talking to your APIs on user’s behalf.
You’d need to have CORS configured on your server to allow your websites talk to your APIs on the backend. In Kubernetes, accessing your API services is usually done with help of an Ingress Controller.
Configuring a CORS on a backend route usually involves setting a few parameters:
origins (list of all origins browser is allowed to talk to),
methods (HTTP methods that browser can use),
headers (a list of headers browser may use in it’s request to the server) and etc.
Unfortunately, all ingress controllers support CORS slightly differently, and getting to grips with those differences can be important when choosing your ingress controller. Let’s have a look at how CORS is configured with two of the more popular ingress controllers: Ambassador Edge Stack and Nginx-Ingress.
For Ambassador Ingress Controller, you would need to configure a CORS for each Mapping, i.e.:
Nginx-ingress does not have it’s own set of CRDs to configure ingress routes, so a set of annotations is used instead:
Manually managing different CORS settings for a lot of deployed APIs can become cumbersome and error-prone, rendering websites and SPAs dysfunctional or, in the worst case, insecure.
Enter Kusk — OpenAPI for Kubernetes
Kusk is a tool that allows you to automatically generate Kubernetes manifests based on your OpenAPI schema — freeing you from burden of manually editing Ingress manifests and making the whole process more enjoyable and less error-prone!
Hello Kusk — OpenAPI for Kubernetes
Adopting a design-first approach to REST APIs with OpenAPI is a common approach and brings many niceties to your API…
For example, Kusk makes it easy to configure CORS on your APIs within
x-kusk extension — i.e. having an OpenAPI schema like this:
Kusk would turn it into a ready-to-be-applied Kubernetes manifest for Ambassador:
Sounds easy, right? But there’s more — what if you want a specific set of endpoints exposed to a browser? Kusk can handle that, too! Just specify
cors option inside an
x-kusk extension on the path level (or even more precisely — at the operation level) — and Kusk will generate a separate set of Mappings for each route with corresponding CORS settings!
Make your OpenAPI schema a real source of truth
Kusk aims to simplify workflows for Developers that adopt Kubernetes, giving the ability to use OpenAPI schemas as a source of truth for configuring cluster resources.
Adopting an OpenAPI to define your APIs bring many advantages to both the developers and consumers of those APIs. Why not make Ops life a little bit easier too?
Kusk can use your OpenAPI schema stored in Git and automatically apply it in a GitOps fashion if you have ArgoCD — working as an ArgoCD plugin!
It is possible to make your OpenAPI schema the real source of truth for your K8s configurations with Kusk - by using it…
Kusk is brought to you by kubeshop.io