Stitchflow
Kubernetes logo

Kubernetes SCIM guide

Connector Only

How to automate Kubernetes user provisioning, and what it actually costs

Summary and recommendation

Kubernetes, the open-source container orchestration platform, does not support SCIM provisioning. While Kubernetes can integrate with identity providers for authentication using OIDC (or SAML through middleware like Dex or OpenUnison), this only handles login verification—not user lifecycle management. Platform teams must manually create service accounts, configure RBAC mappings, and manage cluster access permissions outside of their identity provider workflows.

This creates a significant operational burden for DevOps and platform engineering teams managing multiple Kubernetes clusters. Without automated provisioning, onboarding new developers or SREs requires manual kubectl commands to create accounts and assign appropriate cluster roles. Offboarding becomes a compliance risk, as deprovisioned users in your IdP may retain cluster access through orphaned service accounts or RBAC bindings that weren't properly cleaned up.

The strategic alternative

Kubernetes has no native SCIM. Automate offboarding, user access reviews, and license workflows across every app, including the ones without APIs. We maintain the integration layer underneath. You focus on judgment, not plumbing.

Quick SCIM facts

SCIM available?No
SCIM tier requiredN/A
SSO required first?No
SSO available?Yes
SSO protocolOIDC, certificates, tokens
DocumentationNot available

Supported identity providers

IdPSSOSCIMNotes
OktaVia third-partyNo direct Okta integration for vanilla K8s. Use Dex or OpenUnison for SAML-to-OIDC bridging. RBAC maps groups to roles.
Microsoft Entra IDVia third-partyAzure AKS has native Entra ID integration. Vanilla K8s requires OIDC setup with Azure AD as IdP.
Google WorkspaceVia third-partyNo native support
OneLoginVia third-partyNo native support

The cost of not automating

Without SCIM (or an alternative like Stitchflow), your IT team manages Kubernetes accounts manually. Here's what that costs:

Source: Stitchflow aggregate data across apps with 2+ instances, normalized to 500 employees
Orphaned accounts (ex-employees with access)7
Unused licenses12
IT hours spent on manual management/year101 hours
Unused license cost/year$3,925
IT labor cost/year$6,088
Cost of compliance misses/year$1,741
Total annual financial impact$11,754

The Kubernetes pricing problem

Kubernetes gates SCIM provisioning behind premium plans, forcing significant cost increases for basic user management.

Tier comparison

PlanPriceSSOSCIM
Native OIDCFree
SAML via Dex/OpenUnisonFree (self-hosted)
Managed Kubernetes (AKS/EKS/GKE)Cloud pricing

Authentication and provisioning options

MethodCostUser ProvisioningSSO Support
Native OIDCFreeManual RBAC mapping✓ With OIDC IdPs
SAML via Dex/OpenUnisonFree (self-hosted)Manual RBAC mapping✓ Via middleware
Managed Kubernetes (AKS/EKS/GKE)Cloud pricingCloud IAM integration✓ Platform-specific

What this means in practice

For vanilla Kubernetes clusters

No automatic user provisioning
every user requires manual RBAC role binding
SAML IdP users need Dex or OpenUnison middleware deployed and maintained
Group memberships from IdPs must be manually mapped to Kubernetes RBAC roles
User deprovisioning requires manual removal of role bindings across all namespaces

Real-world scenario: A 50-person engineering team using Okta needs individual kubectl access. Without automation, platform engineers must: 1. Deploy and configure Dex/OpenUnison for SAML-to-OIDC bridging 2. Create ClusterRoleBindings or RoleBindings for each user 3. Map Okta groups to Kubernetes roles manually 4. Update bindings whenever team members join, leave, or change roles

Additional constraints

Middleware dependency
SAML support requires maintaining additional infrastructure (Dex, OpenUnison)
RBAC complexity
Kubernetes RBAC is granular but requires deep understanding of resources and verbs
Namespace proliferation
Role bindings must be created per namespace for namespace-scoped access
Certificate management
Alternative auth methods (client certificates) create additional operational overhead
Audit complexity
User activity tracking requires correlating IdP identities with Kubernetes service accounts

Summary of challenges

  • Kubernetes does not provide native SCIM at any price tier
  • Organizations must rely on third-party tools or manual provisioning
  • Our research shows teams manually provisioning this app spend significant hidden costs annually

What Kubernetes actually offers for identity

Authentication Options (Free/Open Source)

Kubernetes provides multiple authentication methods but no native SAML or SCIM support:

MethodDetails
OIDCNative support for OpenID Connect providers
Client certificatesX.509 client certs for authentication
Service account tokensBearer tokens for service-to-service auth
Static token fileBasic token-based auth (not recommended)
Webhook token authenticationExternal webhook for token validation

SAML limitation: Kubernetes has no native SAML 2.0 support. Teams using SAML-based identity providers (like Okta, Entra ID with SAML apps, or OneLogin SAML) must deploy middleware like Dex or OpenUnison to bridge SAML to OIDC.

Authorization (RBAC)

Kubernetes includes Role-Based Access Control (RBAC) for authorization:

Map IdP groups to Kubernetes roles and cluster roles
Fine-grained permissions for namespaces, resources, and operations
Configured separately from authentication layer
Requires manual RBAC policy creation and maintenance

What's Missing for Enterprise Teams

No user provisioning: Kubernetes has no concept of user lifecycle management. RBAC policies must be manually created, updated, and removed as team members join or leave.

Middleware complexity: SAML integration requires deploying and maintaining additional infrastructure (Dex, OpenUnison, or similar) just to connect your existing identity provider.

Manual group mapping: Every new team, project, or permission change requires manual RBAC configuration updates across clusters.

This approach works for small teams comfortable with YAML configuration but becomes operationally expensive for larger organizations managing multiple clusters and frequent team changes.

What IT admins are saying

Community sentiment on Kubernetes's authentication approach reveals frustration with the complexity of enterprise IdP integration:

  • No native SAML support forces teams to deploy additional middleware
  • OIDC-only approach doesn't work with legacy SAML-based identity providers
  • RBAC configuration becomes complex when mapping IdP groups to cluster roles
  • Additional components like Dex or OpenUnison add operational overhead

Kubernetes does not natively support SAML authentication. You'll need to use a proxy or bridge service like Dex to convert SAML assertions to OIDC tokens.

Teleport documentation

OpenUnison provides a SAML 2.0 identity provider that can be used to provide SSO for kubectl and the Kubernetes dashboard.

OpenUnison project documentation

The recurring theme

Kubernetes's OIDC-only authentication model forces enterprise teams to architect and maintain additional infrastructure components just to integrate with their existing SAML-based identity providers. What should be a straightforward SSO setup becomes a multi-component deployment with additional failure points.

The decision

Your SituationRecommendation
Small dev team (<10 engineers) with simple OIDC setupManual RBAC management is acceptable
Platform team using managed K8s (AKS, EKS, GKE)Use cloud provider's native identity integration
On-premises K8s with SAML-only IdPUse Stitchflow: avoid Dex/OpenUnison middleware complexity
Multi-cluster environments (50+ namespaces)Use Stitchflow: automation essential for RBAC at scale
Enterprise with strict compliance requirementsUse Stitchflow: automated audit trail for cluster access

The bottom line

Kubernetes excels at container orchestration but lacks native SAML support and has no SCIM capabilities. While OIDC works for simple setups, enterprise teams face middleware complexity and manual RBAC management. For organizations needing automated Kubernetes provisioning without the overhead of maintaining authentication proxies, Stitchflow provides the missing identity automation layer.

Make Kubernetes workflows AI-native

Kubernetes has no native SCIM. We build complete offboarding, user access reviews, and license workflows across every app, including the ones without APIs.

Covers apps without native SCIM, including the ones without APIs
Less than a week, start to finish (~2 hours of your time)
Built with your team; extend to anything else in the company
Book a Demo

Technical specifications

SCIM Version

Not specified

Supported Operations

Not specified

Supported Attributes

No native SAML supportRequires OIDC or middleware (Dex, OpenUnison)RBAC for authorization separate from authCertificate and token auth also supported

Plan requirement

Not specified

Prerequisites

Not specified

Key limitations

  • No native SAML support
  • Requires OIDC or middleware (Dex, OpenUnison)
  • RBAC for authorization separate from auth
  • Certificate and token auth also supported

Documentation not available.

Configuration for Entra ID

Integration type

Microsoft Entra Gallery app

Where to enable

Entra admin center → Enterprise applications → Kubernetes → Single sign-on

Azure AKS has native Entra ID integration. Vanilla K8s requires OIDC setup with Azure AD as IdP.

Use Stitchflow for automated provisioning.

Unlock SCIM for
Kubernetes

Kubernetes has no native SCIM. We still automate end-to-end workflows across every app, including the ones without APIs.

See how it works
Admin Console
Directory
Applications
Kubernetes logo
Kubernetes
via Stitchflow

Last updated: 2026-01-11

* Pricing and features sourced from public documentation.

Keep exploring

Related apps

6sense logo

6sense

No SCIM

B2B Revenue Intelligence / ABM

ProvisioningNot Supported
Manual Cost$11,754/yr

6sense, the B2B revenue intelligence platform, has paused SCIM provisioning for new customers until Q4 2026. While existing customers with SCIM enabled can continue using it, new implementations are limited to JIT (Just-In-Time) provisioning through SAML SSO. This creates a significant gap for IT teams managing revenue intelligence access, as JIT only creates users on first login and provides minimal attribute mapping (email, first name, last name only). For an enterprise platform with typical pricing of $55,000-$130,000 annually, the absence of automated user lifecycle management is a substantial limitation. The lack of SCIM until Q4 2026 forces IT teams into manual provisioning workflows for a platform handling sensitive revenue data. While SAML SSO handles authentication, it doesn't address user lifecycle events like role changes, department transfers, or offboarding. This creates compliance risks in revenue teams where access to prospect data and sales intelligence must be tightly controlled. The nearly two-year wait for SCIM restoration means organizations implementing 6sense today face manual user management for the foreseeable future.

View full guide
ActiveCampaign logo

ActiveCampaign

No SCIM

Marketing Automation / Email

ProvisioningNot Supported
Manual Cost$11,754/yr

ActiveCampaign, the marketing automation platform, does not offer native SCIM provisioning on any plan. While the Enterprise plan ($145+/month) includes SAML 2.0 SSO with just-in-time (JIT) provisioning, this only creates user accounts on first login—there's no automated deprovisioning when employees leave or change roles. New SSO users are automatically added to a generic "SSO Users" group with configurable permissions, but IT teams have no way to programmatically manage user lifecycles or enforce granular access controls based on department or role changes. This creates a significant gap for marketing teams that need to manage access to customer data and campaign tools. When employees leave the company or change departments, their ActiveCampaign access must be manually revoked, creating compliance risks and potential data exposure. The lack of automated deprovisioning means former employees could theoretically retain access to sensitive marketing data and customer information until someone manually removes them from the platform.

View full guide
Adyen logo

Adyen

No SCIM

Payments / Fintech

ProvisioningNot Supported
Manual Cost$11,754/yr

Adyen offers SCIM 2.0 provisioning, but only through Okta's integration—there's no native SCIM endpoint. This creates a significant vendor lock-in scenario where your provisioning capabilities are entirely dependent on using Okta as your identity provider. Teams using Azure Entra, Google Workspace, or OneLogin are left with manual user management despite Adyen supporting SAML SSO with these platforms. The Okta integration itself requires maintaining a company account (not just a merchant account) and keeping at least one non-SSO admin for troubleshooting, adding operational complexity. For payment platforms handling sensitive financial data, this provisioning gap creates serious compliance risks. Your finance team, payment operations staff, and developers need timely access to process transactions and manage risk controls, but without automated provisioning, you're stuck with manual onboarding that can delay critical payment operations. The requirement to maintain non-SSO admin accounts also creates a security backdoor that compliance auditors will flag.

View full guide