What is CORS?
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.
Practice
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!
For example, Kusk makes it easy to configure CORS on your APIs within x-kusk extension — i.e. having an OpenAPI schema like this:
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!
Kusk currently supports automatic CORS configuration for Ambassador and nginx-ingress, and Traefik support is coming! For a full options reference, take a look at the documentation.
Your OpenAPI Schema As a Source of Truth for Your Cluster
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. Kusk empowers developers not just with OpenAPI but with its Design First approach as well.
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!
To start using Kusk, refer to our Getting Started guide here. And please, don’t hesitate to give your feedback through Github or hop on our Discord to discuss anything!
Kusk is brought to you by kubeshop.io
Happy days!
/Kusk-team
Thanks to Ole Lensmar and Dmitry Fonarev.
