Hacker News Reader

Hey there! No changes to the api server configuration are required. We've designed Infra around this since AKS/EKS/GKE don't expose the ability to edit api server parameters to users.

View on HN

How does the API server verify the user's token?

Tokens are verified by intercepting API server requests in-cluster against a central root of trust. This is similar to how OpenID tokens from identity providers such as Okta or Active Directory are verified by destination web applications. This works no matter where clusters are hosted (including GKE/AKS/EKS or self-hosted clusters).

How do you avoid configuring the API server to support OIDC?

https://kubernetes.io/docs/reference/access-authn-authz/auth...

Seems like you intercept the request and use an admin service account token then impersonate?

Great question! Most managed Kubernetes services don't support OIDC (and for EKS, which does support custom OIDC providers, it requires restarting the entire control plane to edit the configuration).

Infra runs a lightweight process in-cluster that intercepts requests and verifies them - and yes, this process intercepts requests and then impersonates the correct users and groups.

Reply on news.ycombinator.com