dex VS aws-iam-authenticator

Dex: https://dexidp.io

Recently I looked into having a relatively simple SSO setup for my homelab. My main objective is that I could easily login with Google or GitHub auth. At my previous job I used both JetBrains Hub [1] and Keycloak but I found both of them a bit of a PITA to setup.

JetBrains Hub was really, really easy to get going. As was my previous experience with them. The only thing that annoyed me was the lack of a latest tag on their Docker registry. Don't get me wrong, pinned versions are great, but for my personal use I mostly just want to update all my Docker containers in one go.

On the other hand I found Keycloak very cumbersome to get going. It was pretty easy in dev mode, but I stumbled to get it going in production. AFAIK it had something to do with the wildcard Let's Encrypt cert that I tried to use. But after a couple of hours, I just gave up.

I finally went with Dex [2]. I had previously put it off because of the lack of documentation, but in the end it was extremely easy to setup. It just required some basic YAML, a SQLite database and a (sub)domain. I combined Dex with the excellent OAuth2 Proxy and a custom Nginx (Proxy Manager) template for an easy two line SSO configuration on all of my internal services.

In addition to this setup, I also added Cloudflare Access and WAF outside of my home to add some security. I only want to add some CrowdSec to get a little more insights.

1. https://www.jetbrains.com/hub/

2. https://dexidp.io/

3. https://github.com/oauth2-proxy/oauth2-proxy

3. https://github.com/alex3305/unraid-docker-templates

Another great option is to use https://github.com/dexidp/dex in an authentication setup. In your app, you federate the authentication to dex using OAuth2. Dex then has a pluggable architecture with built-in connectors for many established identity providers using a variety of protocols: Among others OAuth2, SAML 2 but also GitHub, Google, Gitea and so forth.

dex is well-known: https://github.com/dexidp/dex

We used keycloak for openid identity provider as well. It is fine to setup keycloak once. But it is painful share the setup with other engineers.

For local development, we end up using dex (https://dexidp.io). When we need support group/role, we use dex and glauth(https://glauth.github.io). Both dex and glauth can be configured with yaml files. We just created a few yaml files and a docker compose file, every engineer can be brought up the whole environment in a few seconds.

Also https://www.authelia.com and https://github.com/goauthentik/authentik look pretty promising, if you need more advanced features from them.

I added it as an available option (flake) in Dex: https://github.com/dexidp/dex

curl -Lo aws-iam-authenticator https://github.com/kubernetes-sigs/aws-iam-authenticator/releases/download/v0.5.9/aws-iam-authenticator_0.5.9_linux_amd64 chmod +x ./aws-iam-authenticator mkdir -p $HOME/bin && cp ./aws-iam-authenticator $HOME/bin/aws-iam-authenticator && export PATH=$PATH:$HOME/bin echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc

I will be setting up vcluster to work with aws-iam-authenticator. This should work just by following the readme, so I'll be spending extra time automating the setup.

Edit: Because I need to do this for more than one cluster and am creating clusters programmatically (AWS EKS API + CloudFormation/eksctl), I would like to minimize the overhead of creating ServiceAccounts across many cluster contexts, across many AWS accounts. Ideally, the only authentication step involved in creating my clientset is using aws-iam-authenticator to get a token using cluster data (name, region, CA cert, etc). There hasn't been a release of aws-iam-authenticator for a while, but the contents of master allow for the use of a third-party role cross-account role and external ID to be passed. IMO, this is cleaner than using a ServiceAccount (and IRSA) because there are other AWS services the application (the backend API which creates and applies add-ons to these clusters) needs to interact with.

Access to Kubernetes clusters in Amazon EKS is controlled by the AWS IAM Authenticator for Kubernetes. The authenticator runs on the EKS control plane and depends on the aws-auth ConfigMap for configuration settings. Every time you use kubectl to perform actions on the EKS cluster, the AWS IAM Authenticator generates an STS token (AWS Security Token Service). Kubernetes uses the IAM authenticator service to verify the identity of users specified in this security token.

As someone who is a big fan of Teleport, sorry, I just don't get it.

> Teleport doesn't provide identity provider integrations beyond GitHub (e.g. Okta) in their open source project

Right, and if you're a small team (5-10 people, like you're targeting) you don't really need SSO on the infra layer. It's a nice to have, it's best practice, but the truth is, by the time you really need it (enough engineers that account management is a pain), you typically have the budget for an Enterprise license.

> They have a different architecture that involves deploying a centralized proxy service (whereas Infra verifies credentials at the destination infrastructure vs at a central proxy).

So anyway you need to deploy something central to issue certificates. And anyway, if, to quote you, "We plan to make money by running a managed service version of Infra so teams don’t need to host and upgrade Infra manually.", isn't that the central proxy service? Yet the open-source version avoids it somehow?

> We plan to make money by running a managed service version of Infra so teams don’t need to host and upgrade Infra manually

So you want to sell to teams that a) are too small to afford the license for a product like Teleport Enterprise, b) have enough money that they can afford a premium product above and beyond the free offering provided by their Kubernetes vendor, like https://github.com/kubernetes-sigs/aws-iam-authenticator (for EKS), c) are willing to install and maintain another agent on their cluster (infra), but aren't willing to install and maintain the central proxy point?

> we've designed Infra around an extensible REST API from the start whereas Teleport uses GRPC.

This isn't really important from a product perspective. For what it's worth, Teleport started with a REST API; they moved to gRPC because, if I recall correctly, gRPC helped them scale to support larger infrastructure better.

If you're launching a competing product to Teleport, which is now by far the most mature product in the space, then currently, at least from where I'm sitting, you aren't offering sufficient added value compared to the incumbent offerings, which also include CloudFlare Access, Checkpoint Harmony Connect SASE, Hashicorp Boundary (their offerings aren't quite Kubernetes native, but it's the same idea)...

If you’re looking for a cloud provider that caters to identity and access management, then tools like aws-iam-authenticator (AWS) and Anthos Identity Service (Google) are good places to start.

AWS IAM Authenticator.

aws-auth configmap is based on aws-iam-authenticator and has several configuration options: