infra VS aws-iam-authenticator

Check out https://infrahq.com. I saw the founder give a talk at the Civo conference in Feb.

using generics you can even include request and response structs in your handlers. i did that here https://github.com/infrahq/infra/blob/main/internal/server/routes.go

infra

You should try Infra. It works with any flavor of Kube and can hook up Okta, Google, and AD (and anything that supports OpenID Connect). It can pull in your cluster/roles, and set up the cluster/role bindings. It's open source, although there is also a SaaS version if you don't want to self host.

I use them frequently. see https://github.com/infrahq/infra/blob/main/internal/server/routes.go

Github repo: https://github.com/infrahq/infra

if you like Go and backend/infrastructure you might like https://github.com/infrahq/infra. it’s simple identity and access management for kubernetes (and eventually others).

not sure what you’re talking about. we use generics extensively and love it. https://github.com/infrahq/infra

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: