What identity solution works best for a K8s-heavy engineering team?

Alright, let's cut through the marketing fluff. You're running a Kubernetes-heavy shop, your engineers are ssh-ing into nodes, pushing to Git, pulling images, and deploying to clusters. You need an identity solution that actually works for these workflows, not one that just ticks an "enterprise single sign-on" checkbox.

For years, I've seen teams try to force-fit traditional enterprise IAM into a cloud-native environment and it's always a mess. The core question isn't just "which product?" but "which paradigm?" You have two real paths here, and your choice depends on whether you want Microsoft to be your landlord or not.

**Path 1: Entra ID (formerly Azure AD) as the core.** This works *if and only if* your entire universe is already Azure/AKS and O365. The integration is deep. Pod identities (now workload identities) for AKS, managed identity for pipeline agents, and conditional access for admin portals can be cohesive. But the moment you step outside Azure—to AWS ECR, a self-hosted GitLab instance, or a bare-metal K8s cluster—you're building custom OIDC connectors, dealing with app registrations, and the complexity skyrockets. You're paying for a lot of "features" you won't use.

**Path 2: A purpose-built, protocol-centric approach.** This is what I typically recommend. Use a specialized tool that speaks the native language of K8s (ServiceAccounts, OIDC) and modern tooling. Think **Keycloak**, **Dex**, or even **GitLab/GitHub OIDC** as your identity provider, paired with solid RBAC.

Here's a concrete example of a real-world, production-tested setup I've run:

* **For Human Access to K8s clusters:** Use `kubelogin` (oidc-login plugin for kubectl). Your IdP (say, Keycloak) has an OIDC client. Engineers authenticate there, and their groups are mapped to K8s RBAC ClusterRoles.
* **For ServiceAccount/Workload Identity:** Use the K8s cluster's own OIDC discovery URL (most managed clusters provide this). Your CI/CD system (like GitLab CI) authenticates via its own OIDC to the cluster to deploy. No static kubeconfig files lying around.

```yaml
# Example GitLab CI job leveraging OIDC for K8s auth
deploy:
id_tokens:
GITLAB_OIDC_TOKEN:
aud: https://your-k8s-api-server
script:
- |
kubectl create secret docker-registry my-registry
--docker-server=$CI_REGISTRY
--docker-username=gitlab-ci-token
--docker-password=$CI_JOB_TOKEN
--dry-run=client -o yaml | kubectl apply -f -
```

* **For Infrastructure Access (SSH, DB, etc.):** Use the same core IdP (Keycloak, etc.) with a bastion like `Teleport` or `BastionZero`. This gives you a single audit trail.

Entra ID can *technically* do most of this via OIDC, but it feels bolted on. The configuration is buried in enterprise blades and requires Azure AD Premium P1/P2 for anything useful. The cost and complexity become unjustifiable unless you're all-in on Microsoft.

So, my blunt advice:
* If you're 90%+ Azure/AKS and your management demands a single vendor, go Entra ID. Budget for Premium licenses and prepare for some configuration headaches at the boundaries.
* Otherwise, run a dedicated, open-protocol IdP. It's simpler to debug (`kubectl get clusterrolebinding -o wide` tells you more than any Azure portal blade), works identically across clouds, and your engineers can actually understand how their auth works. Start with the protocols (OIDC, SAML, LDAP sync) you need, then pick the tool that implements them cleanly. Don't start with the mega-vendor product and try to map your needs onto it.