The majority of VMware Cloud Foundation 9.1 components can automatically be configured when enabling VCF Single Sign-On (SSO), with the exception of VCF Operations HCX, Log Management (formally VCF Operations for Logs) and VCF Operations for Networks.
These additional VCF components can still be configured to use VCF SSO, however users must first create a new OIDC Client Application from the VCF Identity Broker before completing the VCF SSO configuration for those respective components.
This ability to create custom OIDC Client Application from the VCF Identity Broker brings up an interesting capability for those using vSphere Supervisor and have not deployed VCF Automation (VCFA). vSphere Supervisor can support external identity federation and you would typically create an OIDC Client from your identity provider (e.g. Keycloak). For simplicity purposes, especially for lab or PoC purposes, you could take advantage of the VCF Identity Broker to simply use it as the IdP for vSphere Supervisor and get the benefit of having a single OIDC Client from your IdP.
Note: When VCFA is deployed and configured to use your vSphere Supervisor, it actually becomes the IdP interface where you would then configure your external IdP within VCFA Tenant Portals and VCF Identity Broker is not involved at all to cleanly separate infrastructure configuration from tenant configurations.
Step 1 - Retrieve your vSphere Supervisor Callback URL in vSphere UI by navigating to your vSphere Supervisor Cluster->Configure->Identity Providers
Step 2 - Login to VCF Operations to create a new OIDC Client for your specific vSphere Supervisor by navigating to Manage->Fleet Management->Identity & Access->VCF SSO Overview->Other Components and click on Add Component.
Step 3 - Fill out the Name field with friendly label, select your Identity Broker, Redirect URL will be copied from Step 1 and then click on regenerate Client ID/Secret and make a note of Identity Broker Issuer URL along with the generated Client ID/Secret.
Step 4 - Retrieve the rootCA certificate from your Identity Broker as this will be required to establish trust between vSphere Supervisor and the Identity Broker. You can run the following OpenSSL command and provide the FQDN of your Identity Broker (which you can retrieve in VCF SSO Overview screen).
openssl s_client -connect vcf-idb01.vcf.lab:443 -showcerts </dev/null 2>/dev/null | awk 'BEGIN{c=0;p=0} /-----BEGIN CERTIFICATE-----/{c++;if(c>1)p=1} p{print} /-----END CERTIFICATE-----/{p=0}'
Step 5 - Navigate back to your vSphere Supervisor to configure external IdP. Fill out the Name field with friendly label, Issuer URL will be copied from Step 3 and enter acct for Username claim and group_names for Groups claim and click next.
Step 6 - Copy the Client ID/Secret from Step 3 and proceed to the next step.
Step 7 - Enter group for the additional scopes and then paste the rootCA from Step 4 and click finish to complete the configuration
Step 8 - We are now ready to connect to our vSphere Supervisor using our Identity Broker as the IdP which is then connected to our actual external IdP. We will need to create k8s context by using the VCF Consumption CLI and specify the vSphere Supervisor endpoint along with the username and OIDC for the type:
vcf context create sv01 --endpoint sv01.vcf.lab --username lamw[at]vcf[dot]lab --insecure-skip-tls-verify --auth-type oidc
The command should automatically redirect you to your web browser (or copy the link) and you either be taken to your external IdP for authentication or if you have already logged in, you should see login succeed screen from vSphere Supervisor.
Step 9 - We will now set our k8s context to label we had selected in Step 8, which in my example is sv01
vcf context use sv01
Finally, to ensure that vSphere Supervisor is properly getting your external IdP username/group information, you can run the following command to see what is being passed back, which was extremely useful while initially debugging my setup to understand the required values from earlier steps.
kubectl auth whoami
You are looking to make sure the Username is not returning a UUID and that Groups is returning the group assignment that was configured as part of VCF SSO.
Note: To grant access to vSphere Namespaces for your IdP users and groups, see the documentation for additional details.
Thanks for the comment!