Step into the future with the debut of the Cloud Consumption Interface (CCI) in VMware Aria Automation 8.16.2, offering a revolutionary approach to consuming Kubernetes-based services underpinned by VMware Cloud Foundation.
This sleek and secure self-service solution provides enterprises with a unified experience, empowering them to develop modern applications with enhanced agility, and flexibility, all while maintaining meticulous control over their infrastructure.
However, despite comprehensive official documentation, there's one critical requirement that went unmentioned, a caveat I discovered the hard way . Let's dive into the details.
The Service Broker introduces a new consumption interface for Kubernetes-related services, it all starts with the creation of a Supervisor Namespace. Serving as the equivalent of a Kubernetes namespace but fortified within VMware Cloud Foundation, it introduces true governance, quota management, user permissions, isolation, and more. For a comprehensive guided experience, refer to this resource.
Upon creating the Namespace, you may notice that none of the services are available for users within the Service Broker.
An expanded error box may reveal messages like to the following:
"virtualmachines.vmoperator.vmware.com is forbidden: User "sso:user@Domain" cannot list resource "virtualmachines" in API group "vmoperator.vmware.com" in the namespace "helloworld"
Investigating further, you may discover that the Automation Project user's permissions have not been inherited by the Supervisor Namespace.
A symptom of issue related to the Directory Search Attribute configured in your vIDM.
Presently, CCI exclusively supports the userPrincipalName attribute. Regrettably, transitioning from sAMAccount to userPrincipalName requires deleting and recreating the directory, an inconvenience currently under VMware's radar for resolution.
Cautioulys evaluate this action; when leveraging vIDM in a broader scenario, specially under VCF while you might have a single vIDM for all solutions. Ex NSX-T only supports sAMAccount, so changing it to userPrincipalName, while fixing CCI, it might break NSX-T authentication.
Upon rectification, users can expect seamless access to all services, unlocking the full potential of CCI.
Now you can consume on-deman all Kubernetes Services provided by VCF, from Virtual Machines to full K8s conformant clusters.
Happy Automation !!
