{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/starlingx-oidc/","result":{"data":{"markdownRemark":{"id":"2dd8231e-4596-5aed-ae3f-3fe4153d8da6","html":"<p>One of the biggest improvements the StarlingX platform brings you in the 12.0 release is consolidating <em>all</em> authenticated endpoints to rely on a single OIDC identity provider (IDP) proxy - improving operational simplicity, security, and the end-user experience.</p>\n<h1>Background</h1>\n<p>Up until 12.0, StarlingX shipped a lightweight OIDC proxy based on DEX to provide OIDC support where needed.</p>\n<p>The advantages of that solution relying on DEX is that it can federate multiple backends - commonly the StarlingX local LDAP (OpenLDAP/slapd) and one or more remote directory services (for example Microsoft Active Directory or other LDAPs). Furthermore, Kubernetes can be configured to accept OIDC tokens from that proxy, making kubectl-based access possible with OIDC if the cluster admin enables it.</p>\n<h1>Reaching the consolidation goal - single OIDC IDP for everything</h1>\n<p>In starlingX 12.0 authentication standardizes on a single DEX-backed OIDC flow, which becomes the canonical authentication method for StarlingX-managed endpoints. With that improvement administrators are now able to manage users and groups in one place (the configured backend for DEX) while still choosing the backend type that fits their environment.</p>\n<p>OIDC authentication is supported for:</p>\n<ul>\n<li>Kubernetes APIs / kubectl</li>\n<li>StarlingX REST APIs and CLIs</li>\n<li>the StarlingX web UI (Horizon-based)</li>\n<li>SSH access</li>\n<li>registry.local (container registry flows)</li>\n</ul>\n<p>This reduces duplicated identity configuration, eliminates many special-case auth integrations, and centralizes audit and policy where it makes sense.</p>\n<h2>What this means in practice</h2>\n<p>STX 12.0 enables administrators to start using OIDC out of the box:</p>\n<ul>\n<li><strong>Automatic DEX installation and configuration at install time.</strong> DEX is deployed and pointed to the StarlingX Local LDAP backend by default so that OIDC tokens work for Local LDAP users immediately.</li>\n<li><strong>Kubernetes automatically configured to use OIDC.</strong> Your cluster is now prewired to accept tokens issued by the DEX proxy so kubectl-based workflows can use OIDC immediately after install.</li>\n<li>\n<p><strong>APIs / CLIs optionally OIDC-capable.</strong> StarlingX command-line clients and REST APIs (system, software, fm, sw-manager, dcmanager, etc.) keep Keystone as the default auth method but gain optional OIDC support. Clients can select OIDC using an environment variable or argument (for example: STX<em>AUTH</em>TYPE=oidc).</p>\n<ul>\n<li>StarlingX API/CLI clients now use the OIDC Token from the K8S KUBECONFIG file when generating the StarlingX request</li>\n<li>where the OIDC Token in the KUBECONFIG is populated by the user using the 'oidc-auth' CLI tool to OIDC authenticate with StarlingX's DEX OIDC IDP</li>\n<li>StarlingX API/CLI servers now consult the Kubernetes OIDC configuration to find the configured OIDC IDP details (i.e. for StarlingX's DEX OIDC IDP) which the server's will use for OIDC Token validation.</li>\n</ul>\n</li>\n<li><strong>Role bindings and mappings.</strong> StarlingX role bindings of roles (i.e., admin, configurator, operator, reader) to OIDC users/groups are configurable via a new system service-parameter.</li>\n<li><strong>Validated remote OIDC IDP backends (with MFA).</strong> Relying on a remote OIDC IDP backend for DEX is now a documented and validated configuration in StarlingX- including MFA-capable OIDC IDPs. As an example, StarlingX validated Keycloak as an OIDC backend and walked through browser-based login with MFA for the admin flows.</li>\n<li>\n<p><strong>Support for the kubectl OIDC helper.</strong> OIDC Authentication is fundamentally a browser-based authentication flow. The oidc-login (kubelogin) plugin for kubectl provides improved integration between kubectl CLI flows and the OIDC Authentication Browser flows. This is absolutely required in the case of remote OIDC IDP backends supporting MFA. This plugin launches the browser/OIDC flow, populate KUBECONFIG with the token, and then execute the requested kubectl command.  </p>\n<h3>Configuring OIDC in your environment</h3>\n<ul>\n<li>KUBECONFIG=oidc-login-kubeconfig.yml</li>\n<li>kubectl get pods</li>\n<li>Please visit the following URL in your browser: &#x3C;URL></li>\n<li>\n<p><em>In remote cli case, with local browser, the browser will pop up automatically.</em></p>\n<ul>\n<li><em>In local cli case, with no browser, kubectl will simply wait for browser/OIDC Auth flow to be completed on any device.</em></li>\n</ul>\n</li>\n<li><em>User completes the OIDC Auth flow on the browser, completes MFA if required, the OIDC Token is stored in the KUBECONFIG file and then the kubectl command executes.</em></li>\n<li><em>Subsequent kubectl calls will re-use the OIDC Token until it expires, when it will launch the browser/OIDC flow again.</em></li>\n<li><em>NAME READY STATUS RESTARTS AGE</em></li>\n<li>nodeinfo-c776b9474-qrz74 1/1 Running 0 12h</li>\n<li>nodeinfo-c776b9474-vl5s6 1/1 Running 0 12h</li>\n<li>nodeinfo-c776b9474-zb7bs 1/1 Running 0 12h</li>\n</ul>\n</li>\n</ul>\n<h1>Sneak peek into the plans beyond StarlingX 12.0</h1>\n<p>STX 13.0 will continue the consolidation and widen OIDC coverage:</p>\n<ul>\n<li><strong>Horizon (Web UI) will support OIDC via federated Keystone.</strong> The default remains Keystone username/password, but for OIDC flows the Horizon dashboard will accept logins backed by the DEX proxy and will map OIDC users/groups into Keystone roles automatically (driven by the system service-parameters used for role bindings).</li>\n<li><strong>OIDC plugin support for API/CLI clients.</strong> Improved client-side plugins will make it easier for StarlingX APIs/CLIs to use browser-based OIDC flows and tokens consistently; similar to what was done in STX 12.0 for kubectl.</li>\n<li>\n<p><strong>SSH via OIDC (optional).</strong> OIDC authentication for SSH sessions will be introduced using a PAM module (such as pam-ssh-oidc) that implements browser-based flows to authenticate users.<br>\nThe user experience would look like:</p>\n<ul>\n<li>ssh alice@host<br>\nOIDC authentication required.<br>\nTo continue, open the following URL in a browser: &#x3C;URL><br>\nAnd enter this code: &#x3C;CODE></li>\n<li><em>User completes the flow on a browser on any device (laptop/phone/tablet), completes MFA if required, and the SSH session starts.</em></li>\n<li>alice@host:~$ _</li>\n</ul>\n</li>\n</ul>\n<p>The SSH PAM solution would default to the OIDC IDP configuration used by Kubernetes (i.e., the DEX OIDC IDP proxy).</p>\n<ul>\n<li><strong>registry.local token flow to accept OIDC tokens.</strong> Registry access will still support Keystone tokens, but optional OIDC authentication will be introduced. A common approach used in industry to extend existing simple Registry Token Servers to support OIDC, is to let users provide an OIDC token as the \"password\" for a special-case 'oidc' username. This is the planned approach in short term for StarlingX. Again, the Registry Token Service will default to use DEX OIDC IDP configuration specified in K8S configuration.</li>\n</ul>\n<h3>IDP flexibility: DEX as the federation point</h3>\n<p>A key advantage of this consolidation is the flexibility of the IDP backend. DEX acts as a proxy/federation layer and can connect to a variety of backends:</p>\n<ul>\n<li>local directory service (e.g., OpenLDAP)</li>\n<li>remote LDAP or Microsoft AD (Active Directory) domains (for example, Microsoft's AD)</li>\n<li>OIDC providers such as Keycloak, or other cloud IDPs that support OIDC</li>\n</ul>\n<p>This gives anyone operating a StarlingX environment freedom to choose the backend that meets their organizational requirements, while keeping a consistent authentication surface across the platform.</p>\n<h3>Improved user experience</h3>\n<p>What you gain from this improvement as a user:</p>\n<ul>\n<li><strong>Single place to manage users &#x26; groups.</strong> You can now centralize identity management in the chosen DEX backend (LDAP/AD/Keycloak/etc.) and have those identities honored across kubectl, StarlingX REST APIs / CLIs, Horizon, SSH, and registry access.</li>\n<li><strong>MFA-capable flows for stronger security.</strong> Because DEX can delegate to remote OIDC providers with MFA, the platform can adopt stronger authentication without re-engineering every component.</li>\n<li><strong>Better CLI/browser interoperability.</strong> The oidc-login/kubelogin plugin provides a smooth browser-based flow for CLI users - it handles the redirect, token acquisition, and KUBECONFIG update automatically, including MFA steps.</li>\n<li><strong>Reduced configuration drift.</strong> With one canonical OIDC proxy and a single source of IDP configuration, fewer ad-hoc auth integrations are required and auditing is simpler.</li>\n</ul>\n<h2>Practical notes for administrators</h2>\n<ul>\n<li>When you install StarlingX 12.0, you should expect the DEX proxy and Kubernetes OIDC wiring to be present and configured for Local LDAP users by default.</li>\n<li>If you rely on API/CLI automation that uses Keystone tokens today, those workflows will remain functional; OIDC is opt-in for StarlingX APIs/CLIs initially (STX<em>AUTH</em>TYPE=oidc when you want OIDC).</li>\n<li>If you need MFA, plan to use a remote OIDC backend that enforces MFA (for example Keycloak or an enterprise IdP) and configure DEX to delegate to it.</li>\n</ul>\n<h1>Short summary - why this matters</h1>\n<ul>\n<li><strong>Easier user &#x26; group management:</strong> Consolidating on OIDC (via a single DEX proxy) lets you manage identities in one place and have those identities honored across all authenticated StarlingX endpoints.</li>\n<li><strong>Stronger security (MFA):</strong> Delegation to MFA-capable remote OIDC IDPs raises the bar for authentication without reworking individual services.</li>\n<li><strong>Better CLI usability:</strong> The oidc-login (kubelogin) flow gives a pleasant browser-backed experience for CLI users, including MFA, and works well even in headless scenarios with redirect URLs.</li>\n<li><strong>IDP flexibility through DEX:</strong> DEX supports many backend types (LDAP, AD, OIDC providers like Keycloak) so you can choose the backend that fits your environment while keeping a consistent auth surface.</li>\n</ul>\n<h1>About StarlingX</h1>\n<p>If you would like to learn more about the project and get involved check the <a class=\"siteLink\" href=\"https://www.starlingx.io\" title=\"website\" target=\"_blank\" rel=\"noopener noreferrer\">website</a> for more information or <a class=\"siteLink\" href=\"https://opendev.org/starlingx\" title=\"download the code\" target=\"_blank\" rel=\"noopener noreferrer\">download the code</a> and start to experiment with the platform. If you are already evaluating or using the software please fill out the <a class=\"siteLink\" href=\"https://openinfrafoundation.formstack.com/forms/starlingx_user_survey\" title=\"user survey\" target=\"_blank\" rel=\"noopener noreferrer\">user survey</a> and help the community improve the project based on your feedback.</p>","frontmatter":{"date":"2026/05/18","title":"Consolidating StarlingX Authentication on OIDC","author":"Greg Waines"}}},"pageContext":{"id":"2dd8231e-4596-5aed-ae3f-3fe4153d8da6"}},"staticQueryHashes":[]}