WilliamLam.com

Search Results for: tanzu

VMware Cloud Enterprise Federation with AWS SSO

by // Leave a Comment

Earlier this week I came to learn about a really cool enhancement that was just added to our VMware Cloud Services Console called Connector-less Self-Service Enterprise Federation Setup, it's a bit of a mouth full, but it basically makes configuring identity federation between the VMware Cloud Services Console and other third party identity provider extremely easy.

Identity federation is not a new feature in VMware Cloud and it has been supported for some time now, but it required customers to deploy the Workspace ONE Access connector into their on-premises environment for federating with either their local or third party identity provider. The new method that was introduced is "connector-less" because it does not require any additional infrastructure to be deployed and it also leverages SAML JIT (Just-in-Time) dynamic provisioning.


While looking at the some the pre-defined identity providers, I noticed that AWS Single Sign-On (SSO) was not listed and since we have customers that use both VMware Cloud on AWS and native AWS services, this would certainly be a nice way to provide a common logon experience. Another benefit is also for customers using the new VMware Cloud with Tanzu services with Tanzu Mission Control (TMC), they can now easily manage secure access and provide their their end users the ability to provision and consume Tanzu Kubernetes Clusters (TKC) without the need of exposing them to the underlying infrastructure which is managed by the Cloud Administrators.

This was certainly a few good reasons to try out this new feature, especially as I have never worked with AWS SSO before.

Here is a quick video for those interested in the final logon experience when VMware Cloud is using AWS SSO as the identity provider:

[Read more...]

Quick deep dive into vSphere Namespace roles

by // 1 Comment

Before you can start consuming a vSphere with Tanzu enabled vSphere Cluster, you need to first create and configure a vSphere Namespace. This is a pretty straight forward process (check out this quick video if you are interested). One of the required configuration is to setup up permissions for which user/groups can access and consume the vSphere Namespace using one of the three default roles.


A question was recently raised in the community on the definition of each role since the user was not able to find more details in the official documentation. Here is a quick summary for each role and its functionality:

  • Owner - Can modify and delete vSphere Namespace
  • Can Edit - Can modify vSphere Namespace
  • Can View - Can perform read only operations on vSphere Namespace

Note: I have already shared this feedback with the vSphere with Tanzu Product Manager to help improve our documentation on this topic

There was also a related question on whether these roles mapped into Kubernetes (K8s) layer, which is the Supervisor Cluster in your vSphere with Tanzu enabled vSphere Cluster? This actually got me curious since I am still a novice when it comes to K8s access control (RBAC). I decided to take a closer look and with some trial error, I was able to see how these vSphere Namespace roles, which is a vCenter Server construct maps into the respective K8s constructs within the Supervisor Cluster.

[Read more...]

Quick Tip - How to deploy NSX Advanced Load Balancer (NSX-ALB) with a single Service Engine

by // 1 Comment

I saw an interesting question today from Robert Kloosterhuis in the private vExpert App Modernization Slack Channel who working with vSphere with Tanzu using NSX Advanced Load Balancer (NSX-ALB) and wanted to know if it was possible to deploy NSX-ALB with just a single Service Engine (SE)?

The default behavior of NSX-ALB is to deploy two SE for availability purpose but for testing and/or homelab usage, it could certainly help with resources and time to spin up an environment using NSX-ALB. I was also curious if this was possible and reached out to NSX-ALB Engineering team and within a few minutes, I got a response that not only was this possible to do but pretty easy to configure.

To modify this default behavior, we need to update the Service Engine group prior to SE VMs being deployed. To do so, login to NSX-ALB UI and under Infrastructure->Service Engine Group and then click on the Advanced tab and change the default Buffer Service Engines value of 1 to 0 which will will have NSX-ALB deploy just a single SE VM rather than the default two.


To confirm that our NSX-ALB have been configured correctly, I have enabled vSphere with Tanzu using NSX-ALB and as you can see from the screenshot below, only a single SE VM has been deployed rather than the default behavior of two SE.