 There are several ways Starling X handles security. One of them is through usability, by allowing a user to use an existing centralized identity service for Starling X authentication rather than the more cumbersome route of managing an independent identity service for Starling X. Starling X's integration of the open-source DEX Federated OpenID Connect Identity Provider enables Starling X admins to authenticate Starling X Kubernetes APIs and CLIs against an existing centralized identity provider rather than manage users in a separate local identity provider on Starling X. Starling X Cloud Platform can configure connectivity to one or more remote Windows Active Directory servers as the back-end of the integrated DEX OIDC authentication solution, the OIDC Auth Apps application. The application installs the open-source DEX Federated OIDC Identity Provider that can be configured to proxy authentication requests to one or more LDAPs identity providers, such as Windows Active Directory. By default, this application is in the uploaded state on the system. We should configure the Kubernetes cluster CUBE API server to use the OIDC Auth Apps OIDC Identity Provider for validation of tokens in Kubernetes API requests which use OIDC authentication. We will apply this configuration by executing the commands. Let's create a secret containing the public certificate and private key for the OIDC Auth Apps DEX OIDC client and identity provider server to use and create a secret containing the public certificate of the root CA that signed the DEX OIDC client server certificate. We also need to create a secret containing the public certificate of the root CA that signed the remote Active Directory servers such that we can validate the Active Directory server certificates. Now we will override the OIDC Auth App values in order to create the LDAP connectors with the details of connectivity to the remote Active Directory servers. We have updated the OIDC Auth App setting with the two LDAP connectors to interface with the remote Active Directory servers. We will apply the changes to the app. We wait for the app to reach applied state. Now we check the status. We see it has been applied. Now let's test if authentication works. First let's authenticate an Active Directory user and get a token to use in the Kubernetes API commands. We enter the floating point IP of the system and the port number. We have two login options. One for each configured LDAP connector backend. We will choose WAD-1. Note that the user PV test one should be added as a user in WAD-1 Active Directory server prior to this step. Copy the return token. Return to the CLI. Now we will create a cube config file to access the cube API. This is the IP and port of the cube API. Next we create the context. It is called OIDC-CTX with the user PV test one. Now we update the token. We will use the context we created. Now let's try some Kubernetes commands with this user token combination. Let's have the cube API list some pods. This action should be denied as there is no role binding currently defined for the user or any of the groups the user is in. Access has been denied as expected. We will create a cluster role binding for this user. Binding them to the cluster admin cluster role, giving them full cluster admin privileges. Apply the cluster role binding. We will attempt access again and it is allowed. Let's list all the pods in all namespaces on the system. StarlingX's integration of the open source DEX federated OpenID Connect identity provider enables StarlingX admins to authenticate StarlingX Kubernetes APIs and CLIs against an existing centralized identity provider rather than manage users in a separate local identity provider on StarlingX.