WilliamLam.com

VCF Automation Provider Organization as an OIDC Identity Provider for VCFA Tenant Organizations?

by // 4 Comments

VCF 9.0 Automation (VCF) contains two types of organizations, one for the Provider (also referred to System) and one for the tenants, which are just called Organizations. Both types of VCFA Organizations can be connected to an external Identity Provider (IdP) including OIDC, LDAP and SAML.

The VCFA Provider Organization can be configured to use the new VCF Single-Sign (SSO) feature, which is a capability of VCF Operations and utilizes a deployment of vIDB (Embedded or External) which is the identity broker to your desired external IdP like PingFederate or Okta as an example. While you can connect the VCFA Provider Organization directly to an external IdP, by using VCF SSO, administrators can now seamlessly login to all VCF management components, assuming you have been granted the appropriate permissions within each component.

For VCFA Tenant Organizations, where each organization could represent a completely different customer, such as in a service provider model, each individual VCFA organization can connect to their own independent external IdP, as represented in the diagram below.


For a typical Enterprise, you might only have a single IdP that you would use for both the Provider and Tenant Organizations. If you are using an OIDC IdP, you would need to create one OIDC Client for VCF SSO and then one additional OIDC Client for each organization that you would like to connect to the same OIDC IdP as shown below.


Instead of creating multiple OIDC Clients, could we just leverage the Provider Organization as the OIDC IdP for the VCF Tenant Organizations?

Note: Depending on your external IdP capabilities, you might need to have separate OIDC Clients for controlling multi-factor authentication (MFA) or customized login screen as I have demonstrated with using Keycloak as my external IdP.

[Read more...]

Quick Tip - Configuring vSphere Supervisor Services with self-signed container registry

by // 2 Comments

When deploying additional vSphere Supervisor Services including the new Data Services Operator enabling Database-as-a-Service (DBaaS), the container images that are used are hosted on Broadcom's container registry (projects.packages.broadcom.com).

For air-gapped deployments where you need to use an internal container registry, there is a process to relocate the Broadcom's container images into your own container registry, which has been possible since vSphere 8.0 Update 3.

While attempting to install the DSM Operator Supervisor Service, which had already been relocated into my standalone Harbor registry, I ran into the classic issue where the self-signed TLS certificate could not be trusted as you can see from the screenshot below.


While the validation error message was clear on why the installation will fail, it did not provide any details on how to actually add the trust the self-signed TLS certificate from my container registry.

After checking internally with a few folks, I was able to resolve this, but it took several attempts. I have already made a request to improve the official documentation to make these steps clearer.

[Read more...]

Quick Tip - Auditing configured Per-VM EVC (Enhanced vMotion Compatibility) 

by // Leave a Comment

A request came in last week to help automate the inventory of vSphere Virtual Machines (VMs) that have been configured with the Per-VM EVC (Enhanced vMotion Compatibility) capability.


It is important to understand that if a VM is not configured with Per-VM EVC, it will automatically inherit the configured EVC-mode from the vSphere Cluster. While there are several vSphere API properties that will give you information about the EVC details for a VM, the quickest way to check whether a VM has Per-VM EVC configured is by looking at the FeatureMask property.

Here is a quick PowerCLI snippet that demonstrates the use of this vSphere API:

$vms = Get-View -ViewType VirtualMachine -Property Name, Runtime

foreach ($vm in $vms) {
    if($vm.Runtime.FeatureMask -ne $null -and $vm.name -notmatch "vCLS-") {
        Write-Host "Per-VM EVC Enabled for $(${vm}.name)"
    }
}

Here is an example output when running this script and you can adjust the output based on your needs including exporting it to CSV list/etc.