When I've just started working on this, I thought it would be just peanuts to add SSO to static website, but as it often goes with solving problems on Kubernetes - when you want to solve issue for one service in your infrastructure, get ready to adopting a solution that will solve this problem for all your services.
Of course with something like Ambassador its really become quite easy to introduce, but unless you're already using it - there is no point in dragging it solely for adding SSO for couple of your services (as it's kinda like dragging Kubernetes to deploy three services, which nobody does, right?)
- Kubernetes cluster up and running
- Helm (preferably third generation of it, but its kinda doable even with second, with some caviats) that is configured for deployment on your cluster
- NGINX Ingress configured to expose your services
- Ability to register DNS names in your provider
- Certificate manager configured
- (Optional) ExternalDNS configured
Here we will walk through creating service, vouch proxy for it, to introduce Single Sign On and configuring that SSO using Okta (but of course you're free to use any other OIDC SSO provider)
For that purpose we will create primitive analogue of the service you plan to expose, for experimenting on it.
It will be super simple echo service, that will response with "echo" on our GET request to its home.
Let's create echo.yaml and fill it with following:
https://gist.github.com/4df3e871cb2b95c204b516a54be55f4e
Now after running $ kubectl apply -f echo.yaml we should see something like:
Now, if you have ExternalDNS wait couple minutes for it to sync your services
with your DNS provider and after running curl https://echo.example.com you should be able to see the echo response.
Do you? Awesome! We're halfway there.
If you don't use ExternalDNS - don't get sad. Just go and configure your DNS manually to point to our newly created service.
If you're not admin of your org Okta, then I'd suggest creating private account for testing and playing around, better understandmant and in general
it won't hurt (except increasing enthropy, but its the price we're willing to pay anyhow).
In your dev console https://[your_domain].okta.com/dev/console click on Applications and the create a new one.
It will be of type Web.
On the next page you will be promted for its configuration. Name it to your like and tick on Authorization Code and Refresh Token
among "Allowed grant types". Except of this we're interested only in "Login redirect URIs". Put there https://vouch.example.com/auth
(replace example.com with domain you're owning). Yes, its not existing yet, but we'll be there soon.
Vouch Proxy is SSO solution for NGINX services, and since we're using NGINX Ingress for exposing our services - this is just the tool we need. After its installation we would be able to add SSO to any our service in cluster with just as little as 4 annotation. Isn't it the dream of any person doing infrastructure?
Lets start with adding helm repo, which contains Vouch by running
helm repo add vouch https://halkeye.github.io/helm-charts
Next create file vouch.yaml and fill it with following:
https://gist.github.com/4b68ee38c87eea490ab289d15f420cd7
And after execution of $ helm upgrade --install vouch-proxy vouch/vouch -f vouch.yaml --set config.oauth.client_secret=<your client secret> you will see:
Now the last step on the way to our super simple setup is just adding couple annotations to our service ingress and let the magic happen:
https://gist.github.com/ec5d6e6598fb7f8c8a8813bbda78a0a4
Run the $ kubectl apply -f echo.yaml, check that new configuration is applied and lets go test our SSO.
Navigate to https://echo.example.com and you should be promted to authenticate via Okta!
We're done, great job!