Managing authentication and role-based access control (RBAC) across multiple Kubernetes clusters gets messy fast. Every new cluster introduces another isolated set of identities, roles, and permissions to maintain. Before long, you're dealing with fragmented policies, security gaps, and compliance issues that only grow more severe over time.

Plural.sh solves this by integrating directly with Okta via OpenID Connect (OIDC). Instead of juggling separate identities in every cluster, you authenticate through Okta and let Plural handle the propagation to Kubernetes. This approach ensures consistent, auditable access control across your fleet, while reducing the operational overhead of manually managing credentials and RBAC mappings.

In this article, you'll learn how to configure Plural's OIDC connector with Okta, map user groups to Kubernetes RBAC roles, and enforce uniform access policies across all your environments.

Why Centralized Authentication Matters

Identity is at the heart of cluster security. Kubernetes doesn't manage users on its own; it relies on external providers to handle authentication and authorization. If that identity isn't centralized, every cluster ends up inventing its own version of the truth. This fragmentation causes real problems, including: 

• Inconsistent policies: A developer may have admin rights in one cluster but read-only access in another due to unsynchronized role definitions. This inconsistency leads to confusion and unpredictable user experiences.
• Security gaps: Decentralized management often leaves behind stale credentials or orphaned accounts. Users who leave the company or change roles may still retain unnecessary access to sensitive environments.
• Operational overhead: Each new cluster needs manual duplication and validation of RBAC policies. Over time, this manual work becomes an unmanageable burden.
• Compliance barriers: Demonstrating consistent, auditable access controls across clusters is nearly impossible without a unified system.

Using an enterprise identity provider like Okta helps tackle these risks directly:

• Central policy management: Define groups and policies once in Okta, and they apply across every cluster. This "define once, enforce everywhere" model reduces misconfigurations and strengthens security.
• Role-based access at scale: Instead of binding individual users, you assign RBAC roles to Okta-managed groups. As teams grow or shift responsibilities, access adjusts automatically.
• Auditability and compliance: Okta logs all authentication activity, while Kubernetes records authorization decisions. Together, they provide a complete audit trail of "who did what, where, and when," which is necessary for security reviews and regulatory audits.
• Streamlined onboarding and offboarding: New hires gain immediate access by joining the right Okta group, while departing employees lose access instantly when removed, without cluster-level cleanup.

OIDC makes this possible by acting as the standard protocol for identity federation. OIDC builds on OAuth 2.0 and provides a secure method for exchanging identity tokens between Okta and Kubernetes. With OIDC in place, Kubernetes doesn't need to manage user credentials directly; it simply trusts the tokens issued by Okta. This allows you to enforce uniform security policies across your cluster fleet while relying on a proven standard that is widely supported across enterprise systems.

What Is Plural's OIDC Integration?

Plural.sh is an AI-native Kubernetes management platform built for enterprise-scale, multi-cluster environments. Acting as a unified control plane, it helps you integrate AI into day-2 operations, automate complex upgrades, and manage Kubernetes fleets across clouds, data centers, and edge environments.

Plural's OIDC integration provides the foundation for centralized identity management. Instead of configuring authentication separately for each cluster, you define a single identity layer that applies to your entire fleet. This approach offers three main benefits:

• Centralized identity management: Plural connects to any OIDC-compliant identity provider, including Okta, Azure AD, and Google Identity.
• Multi-cluster consistency: By enforcing identity once at the Plural level, you eliminate configuration drift. Every user signs in the same way, and every cluster enforces the same access rules.
• GitOps-friendly configuration: OIDC settings are managed declaratively in your Git repository. Version control and auditability are built in, and changes propagate automatically through the GitOps pipeline to every managed cluster.

Plural's architecture is designed with the build-versus-buy tradeoff in mind. Instead of maintaining custom federation and RBAC synchronization tooling (a costly, ongoing engineering burden), you can adopt Plural's integrated platform and gain enterprise-grade identity federation out of the box.

Configuring Okta and Plural for Centralized Authentication

This tutorial walks you through configuring Okta and Plural, ensuring that your Kubernetes clusters share a secure and consistent login flow.

Prerequisites

Before you begin, make sure you have the following prerequisites:

• An active Okta account with administrative access. You'll use this account to manage the OIDC application and to test the login flow. If you don't have an organization already, sign up for a free 30-day trial.
• A Plural-managed Kubernetes cluster. This serves as the integration point for centralized identity. For setup guidance, refer to this video tutorial.
• A working knowledge of Kubernetes RBAC concepts, such as `Role`, `RoleBinding`, and `ClusterRoleBinding`. This helps ensure you can map identity groups to appropriate access levels.

Register a New OIDC Application in Okta

Registering an OIDC application in Okta creates the trust relationship between Okta and your Kubernetes environment. This trust allows Okta to issue identity tokens that clusters can validate, enabling secure authentication without relying on local credentials.

To register a new OIDC application, log in to the Okta Admin Console. Go to Applications > Create App Integration, and select OIDC (OpenID Connect) as the sign-in method and Web Application as the application type:

Configure the application settings as follows, and click Save:

After creating the app, copy the Client ID, Client Secret, and Issuer URL (e.g., https://<your-okta-org>.okta.com). You’ll use these values in your Plural configuration to validate tokens issued by Okta:

Configure Plural to Use Okta for Authentication

Once you've registered your OIDC application in Okta, you need to connect your Plural environment. When you enter your Okta credentials, you're telling Plural to trust Okta for identity verification.

Log in to the Plural Console and click on your management cluster:

Under the Login settings, toggle External OIDC and enter the Issuer URL, Client ID, and Client Secret from the Okta Application and click Save:

After a few minutes, the integration will synchronize. Click on the Launch Console, and you should see a Log in with OIDC button, confirming that the integration is active:

From this point on, authentication requests are redirected to Okta, ensuring a centralized identity flow across all your managed clusters.

When you click Log in with OIDC, you’ll be taken to the Okta sign-in page. Enter your Okta username and password, then complete any required multi-factor authentication (MFA):

Once authenticated, Okta redirects you back to the Plural Console, where you're signed in with your Okta credentials. To confirm, click on the Menu in the bottom-left corner and select My Profile. You should see your Okta email and username displayed:

Map Okta Groups to Kubernetes RBAC Roles

Authentication verifies who a user is. Authorization defines what they can do. By mapping Okta groups to Kubernetes roles, you centralize access management in Okta, and Kubernetes enforces permissions at the cluster level.

Define Okta Groups for Cluster Access

Let's create Okta groups that match the roles you want Kubernetes to enforce. This ensures that identity management happens in Okta, while Kubernetes applies permissions at the cluster level. For example, you can use sre for users who need full cluster administrative access and developer for users who need read-only access to resources.

To define Okta groups, log in to the Okta Admin Console. In the left navigation bar, click Directory > Groups > Add Group:

Fill in the group details:

• Name: sre
• Description: Site Reliability Engineers with full cluster admin rights

And click Save.

To assign users to these groups, navigate to the Groups page and click on the group you just created (e.g., sre). Then, click Assign people:

Search for the users you want to add and click +, then select Done:

If someone moves to another team or leaves the company, you only need to update their Okta group membership and their cluster access updates automatically.

Configure Kubernetes RoleBindings and ClusterRoleBindings

With your Okta groups created, the next step is to map those groups to Kubernetes roles. Okta includes a groups claim in the ID token it issues at login. Kubernetes can read this claim and apply RBAC rules based on group membership.

You'll configure this by creating ClusterRoleBindings or RoleBindings (for namespace-specific access).

Create a new manifest file in your GitOps repo to bind the sre group to the cluster-admin role, granting all its members full administrative access:

Create another file for developers to view resources, but not modify them:

Commit these RBAC manifests to your cluster's Git repository. Plural's GitOps pipeline automatically syncs these manifests across all managed clusters. You don't need to manually apply kubectl. 

Confirm the bindings exist:

And inspect the details to confirm the correct mapping:

You should see sre bound to cluster-admin and developer bound to view.

Auditing and Access Verification

Configuring authentication and RBAC is only the beginning. To maintain compliance and security over time, you need ongoing auditing and access verification. 

Test Permissions with kubectl auth can-i

First, run some quick checks to confirm your RBAC bindings are working as expected:

The first command should return yes, since sre is bound to cluster-admin. The second command should return no, since the developer has read-only view access.

Review Kubernetes Audit Logs

Audit logs record every API request, including:

• Who made the request
• What action was taken
• When it happened
• Whether it was allowed or denied

Reviewing these logs helps you identify unauthorized attempts, detect outdated permissions, and refine access policies. In regulated industries, logs also provide a compliance trail.

Automate Onboarding and Offboarding with Okta

Because Okta group membership maps directly to Kubernetes roles, managing user access is as simple as updating group assignments in Okta. You don't have to touch Kubernetes manifests every time a user joins or leaves.

Add a User to a Group (Onboarding)

To add a user to a group, log in to the Okta Admin Console and go to Directory > People.

Click on the user you want to assign.

In the user profile, select Groups and choose the group (e.g., sre or developer) you want to add:

The user now has Kubernetes access according to the RBAC binding for that group. No cluster-side change is required.

Remove a User from a Group (Offboarding)

To remove a user from a group, log in to the Okta Admin Console and go to Directory > Groups. Click on the group your user is in  (e.g., developer), search for the users you want to remove, and click the X to the right of the user:

If someone moves to another team or leaves the company, you only need to update their Okta group membership—their cluster access updates automatically.

Conclusion

Integrating Okta with Plural's OIDC connector gives you a single, trusted source for Kubernetes authentication and authorization. It replaces scattered credentials and manual RBAC updates with a centralized, auditable system that's secure and easy to manage.

By moving identity control into Okta and letting Plural enforce it across your clusters, your team gains consistency without extra overhead. If you're expanding your Kubernetes environment, Plural can simplify your operations. Features like GitOps automation, built-in backups, and multi-cluster federation help you scale confidently while maintaining stable and compliant environments.