DigitalOcean has moved OpenID Connect single sign-on for DigitalOcean Kubernetes (DOKS) to general availability, closing a gap that has quietly bothered platform teams since the service launched: DOKS clusters could previously only be accessed with long-lived, hand-distributed kubeconfig tokens rather than through the identity provider an organisation already uses for everything else.
What actually changed
Clusters can now authenticate users through an external OpenID Connect provider, including Okta, Keycloak, Auth0, authentik, or JumpCloud, instead of static token-based authentication. Each cluster carries its own independent SSO configuration, set with an issuer URL and client ID from the identity provider and managed through doctl, the DigitalOcean API, or Terraform. That per-cluster scoping matters in practice: a development cluster can allow a broad engineering group access while a production cluster restricts entry to a much smaller, more tightly governed set of identities, without the two configurations interfering with each other.
The operational win is in revocation. Because token issuance and validation now run through the identity provider rather than a static kubeconfig file, deactivating a departing employee’s account in the IdP removes their cluster access immediately. Under the old token model, offboarding meant tracking down every kubeconfig that had ever been generated and manually invalidating it, a step that is easy to skip under time pressure and is exactly the kind of gap auditors look for.
Why this is more than a convenience feature
Static, long-lived Kubernetes credentials are a recurring theme in cluster compromise post-mortems: a token copied into a CI variable, shared in a support ticket, or left in a former contractor’s laptop backup can grant standing access long after anyone remembers it exists. Centralising authentication through an IdP that already enforces multi-factor authentication, conditional access policies, and session expiry brings Kubernetes access control in line with how the rest of the organisation’s infrastructure is already governed, rather than treating the cluster as a separate credential silo.
For European teams operating under NIS2 or working toward ISO 27001, the ability to demonstrate a single point of identity governance and immediate revocation across cloud infrastructure, including Kubernetes, is a meaningfully easier compliance story than explaining a manual token-rotation process to an auditor.
What to do with it
If your organisation runs DOKS clusters on shared kubeconfig tokens today, this is worth migrating deliberately rather than leaving for later: audit which identities currently hold cluster access, decide per-cluster policy for dev, staging, and production, and confirm your CI/CD pipelines are updated to use service accounts or workload identity rather than a human’s SSO session where automation needs access.
If you want help planning that migration, auditing current Kubernetes access sprawl, or wiring DOKS SSO into your existing identity provider correctly the first time, contact Excello Digital. We help European DevOps teams close exactly this kind of access-governance gap.