rutgerblom.com

When working with a VCF 9 lab, one of the small but recurring questions is how to access the administrative interfaces in a clean way.

A VCF 9 environment ends up with several management endpoints. VCF Operations, VCF Automation, vCenter, and NSX Manager all have their own interfaces. In a lab this often means either exposing those interfaces directly to the network you are working from, or relying on a traditional jump host with a browser installed.

For this setup I wanted to try a slightly different pattern: using Kasm, which provides browser-based workspaces, as an access layer in front of the VCF management stack.

The idea is simple. My workstation connects to Kasm over HTTPS. Kasm provides the browser session. That browser session has access to the internal VCF administrative interfaces. Authentication to Kasm is handled by Keycloak, while supporting services such as DNS and certificates are provided by the lab service node.

+-------------------+
| Admin Workstation |
+-------------------+
          |
          | HTTPS
          v
+-------------------+        OIDC / Login         +-------------------+
|       Kasm        | <-------------------------> |     Keycloak      |
| Browser Workspace |                             | Identity Provider |
+-------------------+                             +-------------------+
          |                                                 ^
          | Browser access                                  |
          | to internal lab interfaces                      |
          v                                                 |
+--------------------------------------------------+        |
|                VCF 9 Lab Stack                   |        |
|                                                  |        |
|  +----------------+   +------------------------+ |        |
|  | VCF Operations |---| Central VCF SSO Config |-|--------+
|  +----------------+   +------------------------+ |
|                                                  |
|  +----------------+   +----------------+         |
|  | VCF Automation |   |    vCenter     |         |
|  +----------------+   +----------------+         |
|                                                  |
|  +----------------+                              |
|  |  NSX Manager   |                              |
|  +----------------+                              |
+--------------------------------------------------+

One of the main reasons for using Kasm in this setup was that I did not want to introduce yet another login layer. Its OIDC support solves that nicely. By using Keycloak for Kasm authentication, and the same Keycloak instance for VCF SSO, the access flow becomes much cleaner. I still get a separate Kasm session and separate VCF sessions, but from a user perspective I authenticate once and can then reach the VCF interfaces from the Kasm workspace without another username and password prompt.

This is a lab pattern, not a production access architecture, but it is a useful way to keep VCF management access a bit more controlled without exposing every administrative GUI directly to my workstation.

Lab Setup and Assumptions

For this article I used a VCF 9.1 lab with the main administrative interfaces available on internal lab networks. The interfaces I wanted to access through Kasm were VCF Operations, VCF Automation, vCenter and NSX Manager.

Kasm was deployed on a Debian Linux machine using the Kasm “Single Server” installation model. This keeps the setup simple and fits well for a lab environment where all Kasm services run on the same host.

Keycloak was used as the identity provider for Kasm through OIDC. The same Keycloak instance was also used by VCF SSO, configured centrally from VCF Operations.

The supporting lab services, such as DNS and certificates, were provided by my lab service node. In my case this is Provider Box, but the pattern does not depend on that specific implementation. What matters is that Kasm can resolve the Keycloak endpoint, trust the certificate chain, and reach the VCF administrative interfaces from the browser workspace.

For this article I assume that:

• Kasm is already deployed
• Keycloak is already running
• VCF SSO is configured to use Keycloak
• The VCF administrative interfaces are reachable from the Kasm workspace
• Internal DNS and certificates are under your control

Configuring Keycloak for Kasm

The first step was to create a dedicated client in Keycloak for Kasm.

In my lab I created a client called kasm in the same Keycloak realm that is also used by VCF SSO. The important part here is that Kasm acts as an OIDC client, while Keycloak remains the identity provider.

For the client configuration I used the standard authorization code flow. Client authentication was enabled, which means Kasm uses a client secret when exchanging the authorization code for tokens.

The redirect URI must match the callback URL shown by Kasm. In my setup that was:

https://kasm.sddc.lab:6443/api/oidc_callback

Note that the use of port 6443 is specific to my lab. A default Kasm single-server installation normally uses port 443, so adjust the redirect URI to match how Kasm is exposed in your own environment.

Below is a sanitized example of my Keycloak client configuration for Kasm. The important parts are the client ID, the redirect URI, client authentication, the standard authorization code flow, and the basic OIDC scopes used by Kasm.

{
  "clientId": "kasm",
  "name": "kasm",
  "description": "Kasm OIDC client",
  "enabled": true,
  "alwaysDisplayInConsole": true,
  "clientAuthenticatorType": "client-secret",
  "secret": "REPLACE_WITH_YOUR_CLIENT_SECRET",
  "redirectUris": [
    "https://kasm.sddc.lab:6443/api/oidc_callback"
  ],
  "webOrigins": [
    "+"
  ],
  "bearerOnly": false,
  "consentRequired": false,
  "standardFlowEnabled": true,
  "implicitFlowEnabled": false,
  "directAccessGrantsEnabled": false,
  "serviceAccountsEnabled": false,
  "publicClient": false,
  "frontchannelLogout": true,
  "protocol": "openid-connect",
  "attributes": {
    "post.logout.redirect.uris": "+",
    "frontchannel.logout.session.required": "true",
    "backchannel.logout.session.required": "true",
    "backchannel.logout.revoke.offline.tokens": "false",
    "display.on.consent.screen": "false"
  },
  "fullScopeAllowed": false,
  "defaultClientScopes": [
    "web-origins",
    "profile",
    "email"
  ],
  "optionalClientScopes": [],
  "access": {
    "view": true,
    "configure": true,
    "manage": true
  }
}

I initially tried to include group mapping as well, but since it was not required for this first version of the lab, I kept the configuration focused on basic authentication.

At this point Keycloak had the required client-side configuration in place: a client ID, a client secret, and a valid redirect URI.

Configuring OIDC in Kasm

With the Keycloak client in place, the next step was to configure OpenID Connect in Kasm.

In my lab I used the following Keycloak realm endpoints:

Authorization URL
https://auth.sddc.lab:8443/realms/provider-box/protocol/openid-connect/auth
Token URL
https://auth.sddc.lab:8443/realms/provider-box/protocol/openid-connect/token
User Info URL
https://auth.sddc.lab:8443/realms/provider-box/protocol/openid-connect/userinfo

I also configured the issuer as:

https://auth.sddc.lab:8443/realms/provider-box

The requested scopes were kept simple:

openid
profile
email

For the username mapping I used:

preferred_username

The important part is that the redirect URL shown by Kasm must match the redirect URI configured on the Keycloak client. Once those values matched, Kasm could redirect the user to Keycloak and process the callback correctly.

Creating the OIDC User in Kasm

With OIDC configured, I also created a matching OIDC user in Kasm for the lab account:

lab-admin

For this lab I kept the mapping simple. The username returned by Keycloak needs to match the OIDC user created in Kasm, so in my case the Keycloak user and the Kasm OIDC user were both named lab-admin.

I did not configure group mapping for this first version. Kasm supports that as well, but for this lab I only needed a working OIDC login flow for the lab-admin user.

Certificate Trust

The most time-consuming part of the setup was not OIDC itself, but certificate trust.

In my lab, Keycloak was using a certificate issued by my internal CA. The browser could reach Keycloak just fine, and the initial login flow worked, but Kasm still failed when processing the OIDC callback.

The reason was that the Kasm API container also needs to trust the certificate chain used by Keycloak. During the callback, Kasm exchanges the authorization code for tokens by calling the Keycloak token endpoint from inside the kasm_api container. If that container does not trust the Keycloak certificate issuer, the token exchange fails.

The error in the Kasm API logs looked like this:

SSLCertVerificationError: certificate verify failed: unable to get local issuer certificate

In my case the fix was to add the internal CA certificate chain to the trust store used by the Kasm API container. Since Kasm containers run with a read-only root filesystem, this was not as simple as copying a certificate into the container. I ended up creating a custom CA bundle on the host and mounting it into the container path used by Python certifi.

A useful validation test was running a small Python request from inside the Kasm API container:

sudo docker exec -i kasm_api python3 - <<'PY'
import requests
url = "https://auth.sddc.lab:8443/realms/provider-box/.well-known/openid-configuration"
r = requests.get(url)
print(r.status_code)
print(r.json()["issuer"])
PY

The expected result was:

200
https://auth.sddc.lab:8443/realms/provider-box

The important takeaway is this: it is not enough that your workstation trusts Keycloak. Kasm itself also needs to trust Keycloak from inside the container that performs the OIDC token exchange.

The Result

After the OIDC configuration was in place, I created a small set of Kasm link workspaces for the main component GUIs in the VCF 9 lab.

The result is a simple landing page for the lab-admin user with direct access to the main VCF 9 component GUIs from inside Kasm. I also added a Terminal workspace as a small utility workspace for lab administration and quick troubleshooting from the same access layer.

In this setup the user signs in to Kasm using Keycloak, launches the required link workspace, and opens the selected VCF 9 component GUI from the browser session provided by Kasm. Since VCF SSO also uses the same Keycloak instance, the user can access those GUIs without another username and password prompt.

For a lab this gives me the access pattern I wanted: one browser-based entry point, no direct exposure of every VCF administrative GUI to my workstation, and no extra local Kasm login in front of VCF SSO.

Closing Thoughts

This ended up being a useful access pattern for my VCF 9 lab. Kasm gives me a browser-based entry point, Keycloak provides the identity layer, and the VCF interfaces remain reachable from the Kasm workspace rather than directly from my workstation.

Kasm can clearly do more than what I used here. It supports more advanced designs with egress providers, connection proxies and additional control over how sessions reach internal resources. For this lab, that would have been overkill. A simple single-server deployment with link workspaces was enough to prove the pattern and keep the setup understandable.

The main lesson for me was that the OIDC configuration itself was fairly straightforward, but the surrounding details mattered: DNS, redirect URIs, client secrets, and certificate trust from inside the Kasm containers. Once those pieces were in place, the result was exactly what I wanted: a cleaner way to access the VCF lab interfaces without adding another separate login step.