kube-oidc-proxy VS infra

It is sort of a roundabout way, but I sync Active Directory to a Keycloak realm, then use OIDC auth with kube-oidc-proxy (https://github.com/jetstack/kube-oidc-proxy) and kubelogin (https://github.com/int128/kubelogin) for OIDC-based auth to the api server.

Yes, I setup a cluster with no SPFs. That means an HA setup for the external load balancer. I use HAProxy for my ELB, and setup 2 instances with a VRRP + keepalived to provide HA to the ingress controller. I run the control plane private, accessible only from localhost. I setup kube-oidc-proxy (https://github.com/jetstack/kube-oidc-proxy) to expose the API server with single sign-on on the ingress controller, and use the kubelogin plugin (https://github.com/int128/kubelogin) to provide OIDC support to kubectl. I then setup Keycloak to handle OIDC/OAuth2/SAML and syncing to Active Directory, and setup groups in Active Directory to control acccess to clusters. Devs each get their own namespace in the dev cluster, with mostly cluster-admin access to their namespace. Staging/Prod clusters are locked down, with read-only access to devs. Thanks to the OIDC auth to the APIServer, when employees are onboarded & offboarded, we only need to add/remove them from groups in Active Directory and everything else just magically syncs.

kube-oidc-proxy (OIDC to Kubernetes API servers where OIDC authentication is not available)

I use the kube-login plugin for kubectl (https://github.com/int128/kubelogin) along with the kube-oidc-proxy (https://github.com/jetstack/kube-oidc-proxy), using Keycloak as my OIDC provider (https://www.keycloak.org) and doing LDAP synchronization to Active Directory.

We use Keycloak for this purpose. We deploy an OIDC-proxy to the kube-api (https://github.com/jetstack/kube-oidc-proxy), then use the kubectl plugin 'kubelogin' (aka oidc-login if you use krew - https://github.com/int128/kubelogin). This gives us the ability to have no user secrets in our KUBECONFIG, and to use Keycloak's Active Directory/LDAP user & group federation to control access to clusters. With this, downloading the KUBECONFIG is self-service, and adding users to new clusters is as easy as adding them to a group in AD.

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