VMTECHIE.blog

Tag: security

  • VCF Automation – Tenant Management

    VCF Automation – Tenant Management

    In today’s multi-tenant cloud environments, VMware Cloud Foundation Automation (VCFA) offers a robust layered architecture that seamlessly bridges enterprise-grade infrastructure management with developer-ready self-service capabilities.

    By clearly separating responsibilities—from VMware Cloud Service Providers who manage the physical and virtual infrastructure, to organization administrators who allocate resources, and finally to developers who consume them—VCFA enables efficient resource governance, operational consistency, and scalability. This structured approach not only supports multi-tenancy and workload isolation but also accelerates innovation by empowering end users to deploy applications and services quickly within well-defined boundaries.

    Why Tenant Management Matters?

    Tenant management is more than just dividing resources—it’s about ensuring cost efficiency, security, scalability, and compliance in a shared infrastructure. In VCFA, these capabilities allow VMware Cloud Service Providers to maximize utilization without compromising performance or governance for individual tenants.

    Key concepts to understand from both the Provider and Tenant perspectives:

    Projects

    Projects control user access to namespaces and user ownership of provisioned resources. All organizations are created with a default project. The default project is empty and does not have any namespaces or users.

    Example: A VMware Cloud Service Provider might assign a dedicated project to each customer department for clearer billing and isolation.

    Regions

    The Regions page lists all the regions where the organization has a quota in. Organizations can have a quota in one or many regions. Your provider administrator assigns the regional quota to your organization. Quota in a region can come from one or many vSphere Zones within that region.

    Example: A global enterprise hosted by a VMware Cloud Service Provider might have quotas in Asia and Europe to ensure low-latency access for local teams.

    Namespace Class

    Namespace classes are templates for namespace provisioning. These templates can be used to standardize namespace attributes, like utilization limits, reservations, VM classes, storage classes, and content libraries. organizations comes preconfigured with three default namespace classes (small, medium, and large), which are meant to serve as example templates. The only different attributes among these built-in templates are the CPU and Memory limits. Administrators can use these templates as-is or can modify them to suit their needs.

    Namespace

    Projects are the central construct for organizing and allocating infrastructure resources to tenants or teams. As the organization administrator, you manage and distribute infrastructure by assigning namespaces to projects. When configuring a project, you must add at least one namespace so that users within the project can begin provisioning workloads such as virtual machines, VMware Kubernetes Service (VKS) clusters, or other supported resources. Namespaces act as scoped resource pools, defining limits for CPU, memory, and storage to ensure fair allocation and performance consistency. Each namespace is tied to a Virtual Private Cloud (VPC) and a namespace class, which in turn is associated with at least one zone to determine placement and availability. This structure not only enforces resource governance but also enables automation workflows to deploy consistently within predefined boundaries. All organizations are created with a default project, which is initially empty and contains no namespaces or users, providing a baseline starting point for configuration.

    Example: A tenant of a VMware Cloud Service Provider might create separate namespaces for development and production to avoid accidental resource conflicts.

    Virtual Private Clouds (VPCs)

    A Virtual Private Cloud (VPC) in VMware Cloud Foundation Automation (VCFA) offers an isolated networking environment that can be associated with one or more namespaces. Organizations can create multiple VPCs and assign each to specific namespaces based on workload or isolation requirements.

    Each VPC is an independent network and supports three types of IP address spaces, each offering different levels of reachability:

    • Private CIDRs: These addresses are internal to the VPC and are not routable outside without NAT. They are managed by the VPC administrator and do not need to be globally unique, allowing reuse across multiple VPCs.
    • TGW Private IP Blocks: These IP blocks are scoped at the organization level and are advertised through the Transit Gateway (TGW) within the organization. Organization admins define these blocks, and project admins can allocate subnets from them for their VPCs. This enables direct communication between VPCs in the same organization using the TGW Private IP space.
    • External IP Blocks: Managed by the provider admin, these IPs enable outbound access through Source NAT. Organization admins can assign subnets from provider-defined external blocks, giving workloads external connectivity while still using internal addressing.

    You can choose to deploy a separate VPC per namespace for stricter isolation, or share a VPC across namespaces where network separation is not required.

    Transit Gateways

    Each organization has a transit gateway which provides connectivity to the provider gateway within the organization. One or more VPCs are connected to the transit gateway, and that connection is defined by a VPC connectivity profile. Each VPC has connected workloads and a private subnet. SNAT rules translate addresses from this private subnet to a public address in the IP spaces block. This infrastructure enables the organization and its workloads to connect to external networks.

    You can view what transit gateways are available to your organization on the Manage & Govern > Networking > Transit Gateways page.

    IP Management

    Provider can use IP Spaces to manage their IP address allocation needs. IP Spaces provide a structured approach to allocating public IP addresses to different organizations, enabling connectivity to external networks.

    An IP space consists of a set of CIDR blocks that are reserved, these CIDRs must be dedicated to  and used by organization administrators as they configure services. An IP space can only be IPv4.

    Organization administrators can create and manage the private IP blocks within their organization. there tenant can view external IP address blocks assigned to this organization by a provider. You can also create and view private TGW IP address blocks for the entire organization to use. Finally, you can view private VPC IP address blocks that are applicable to specific VPCs.

    In essence, VMware Cloud Foundation Automation’s tenant management capabilities provide a structured, role-based framework for organizing projects, namespaces, VPCs, transit gateways, and IP resources. By aligning provider and tenant responsibilities, VMware Cloud Service Providers ensure secure isolation, consistent governance, and streamlined automation—empowering organizations to scale efficiently while maintaining full control over infrastructure and networking resources.

  • Navigating the Shift: From VMware Cloud Director to VCF Automation in VMware Cloud Foundation 9

    Navigating the Shift: From VMware Cloud Director to VCF Automation in VMware Cloud Foundation 9

    VMware Cloud Foundation 9 (VCF 9) has officially launched, introducing a next-generation Cloud Management Platform — VCF Automation (VCFA). This new platform supersedes both Aria Automation and VMware Cloud Director (VCD). This blog is specifically aimed at those familiar with VCD and looking to understand how VCFA compares — what remains familiar, what’s changed, and how to navigate the shift.

    It’s important to note that VCFA is not a simple rebranding of existing tools. It is a new solution built with purpose, though it incorporates core components from its predecessors. The provider-facing layer, known as Tenant Manager, is built on the VCD codebase, so the UI and APIs will feel familiar to seasoned VCD administrators. On the other hand, the tenant experience draws heavily from Aria Automation, introducing a modernized interface and capabilities that will appear significantly different — especially for users coming from a traditional VCD background.

    Why VCFA?

    Modern enterprises and service providers are navigating increasingly complex environments — hybrid, multi-cloud, containerized, and AI-driven workloads are the new normal. VMware has responded with VCFA: a cloud automation solution tightly integrated with VCF 9 that provides:

    • Unified multi-tenant management
    • Seamless integration across compute, storage, and networking
    • Robust self-service capabilities for both providers and tenants
    • Compliance-ready, policy-driven automation

    This is not just an incremental upgrade. VCFA is a next-generation platform, built to be extensible, resilient, and future-proof.

    How VCFA Differs from VCD and Aria Automation

    Let’s break it down into provider and tenant perspectives:

    Provider Experience – Tenant Manager

    The provider-facing component of VCFA is called Tenant Manager.

    • It leverages the codebase from VCD, meaning administrators familiar with VCD will find the UI and APIs instantly recognizable.
    • Tasks such as creating tenants, managing quotas, assigning resources, and configuring networks follow a some what similar structure to VCD.
    • However, Tenant Manager is fully integrated with VCF’s architecture, eliminating dependency on external orchestration layers.

    In essence, Tenant Manager modernizes VCD’s core capabilities while maintaining continuity for service providers.

    Tenant Experience – VCFA UI and APIs

    For tenants, the VCFA experience is heavily influenced by Aria Automation but redesigned for simplicity and control:

    • New self-service portal tailored for tenant-level resource provisioning
    • Integrated access to IaaS, network services, Kubernetes (via VKS), and more
    • Native support for day 2 operations, approvals, cost visibility, and policy governance
    • UI/UX reflects a cloud-native mindset, empowering developers and app teams

    If you’re a tenant used to the VCD interface, the VCFA UI may initially seem unfamiliar — but it brings greater power, flexibility, and visibility.

    Provider Management

    The VCF Automation Provider Management Portal is a dedicated interface for Provider Administrators and to access it, type https://vcfa.example.com/provider and to log in for the first time, you must use default administrator/admin account with local user and password which you set up during the installation.

    You can use the Quick Start wizard in VCF Automation to quickly create an organization with predefined settings, streamlining the initial setup process. This is a convenient alternative to manually configuring each component and is especially useful for setting up a test or evaluation environment to explore the platform’s capabilities.

    NOTE – VCF Automation 9.0, only active-standby mode is supported for NSX Tier-0 Gateways. In active-standby mode, an elected active member processes the traffic. If the active member fails, a new member becomes active.

    Alternatively, you can use the manual wizard in VCF Automation to set up each component individually—Region, Organization, IP Space, Provider Gateway, and Tenant Networking—giving you full control and customization over your environment. In this blog post, I’ll walk you through that step-by-step process to help you understand how to configure a tenant from the ground up.

    Region

    In VCFA, a region represents a logical grouping of compute, storage and networking resources, typically associated with one or more vCenter Server instances and a shared NSX instance.

    NSX Local Manager – provides software define networking for the region, select the NSX Manager instance that integrates with the vCenter instances you want to use for the region

    Note: A single NSX Manager instance must be integrated with all vCenter instances within a region.

    Supervisor(s) – Inside a Region we have one or more Supervisors and provides compute infrastructure for the region, list shows all available Supervisors for NSX Manager instance that you choose in above step.

    Storage Class(es) – shows all storage classes across the selected Supervisors.

    Organisations

    In VMware Cloud Foundation Automation (VCFA), Organizations are foundational constructs used to separate and manage tenants and providers in a multi-tenant private cloud environment. These organizations define the boundaries for resource allocation, identity management, policies, and service consumption.

    VCFA introduces two main types of organizations:

    Provider Consumption Organization

    A PCO ( Provider consumption organization ) is created which the provider can use to share blueprint catalog, workflows with other tenant organizations , this must be enabled by going to Administration > Feature flags and enable PCO Organization feature flag

    Tenant Organization

    Each tenant/customer is onboarded into VCFA as a separate organization, Tenants get:

    • Isolated access to their own VMs, networks, storage, Kubernetes clusters, etc.
    • Self-service portal and/or API access
    • Resource limits defined by the provider
    • Option to integrate with their own identity providers (IdP) (e.g., SAML, LDAP)
    • Custom catalogs or services if published by the provider

    When onboarding a new customer in VCFA:

    • You (the provider) create a Tenant Organization.
    • Allocate region, supervisor and zones (resources – e.g., 10 GHz, 10 GB RAM).
    • Assign VM classes and storage classes
    • Configure access control (create local users)
    • Let the customer use VCFA UI or API to deploy/manage their workloads.

    VCFA Organizations are essential to enabling multi-tenancy, isolation, and governance in VCFA.They help service providers manage multiple customers securely and efficiently. Each org has its own identity, resource limits, users, services, and policies.

    IP Space

    IP spaces offer a structured approach for providers to allocate IP addresses to different organizations, enabling connectivity to external networks. You can use quotas to control usage. For internal organization communications, organizations can self-manage their own IP address blocks.

    Go to Networking > IP spaces to create a new IP Space and set quotas. IP Blocks are created in NSX. IP Blocks represent IPs used in this local datacenter, south of the Provider Gateway. IPs within this scope are used for configuring services and networks.

    External Reachability represents the IPs used outside the datacenter, north of the Provider Gateway.

    Provider Gateway

    A Provider Gateway in VCFA is the logical network boundary between the provider-managed infrastructure and external environments. It serves as the entry/exit point for all traffic coming in and going out of tenant environments.

    A provider gateway leverages VCF Networking T0s or T0 VRFs, and associates them with IP addresses from IP spaces that can be advertised from those gateways. A provider gateway can be assigned to one or more organizations.

    To add a provider gateway, first you must create an Active Standby tier-0 gateway in the NSX Manager associated with the region to back it. You can create the tier-0 gateway in the NSX Manager UI or by using the NSX Policy API.

    If you want to add a tier-0 gateway that is backed by a VRF gateway in NSX, you must also create a VRF gateway that is linked to the tier-0 gateway.

    • Enter a name and, optionally, a description for the new provider gateway.
    • From the drop-down menu, select the region of the tier-0 gateway, and click Next.
    • Select a tier-0 gateway from the list, and click Next.
    • Select one or more IP spaces to associate with the provider gateway, and click Next.
    • Review the network settings and click Create.

    Region Network Settings (Tenant Networking)

    When you configure networking for a Region in VCFA, you’re defining how tenant workloads in that region will connect—both internally and externally. This includes:

    Click on “START” will take to Organization page, there select Organization for which you want to configure Networking and click on CONFIGURE

    • Select the Region – choose the appropriate region where this organization’s resources will be provisioned, then click Next.
    • Choose a Provider Gateway – select a provider gateway to connect the organization’s virtual network to external networks (e.g., internet or upstream services), then click Next.
    • Assign an Edge Cluster – Pick the Edge cluster where the VPC services for this organization will operate. (You may choose the same cluster associated with the Tier-0 provider gateway, or a different Edge cluster depending on your resource planning)
    • Review and Confirm – Review all configured network settings. Once validated, click Create to complete the network setup for the organization.Select a region, and click Next

    This blog post provides a comprehensive, step-by-step walkthrough of how to manually onboard a tenant in VMware Cloud Foundation Automation (VCFA) by configuring key components such as Regions, Organizations, IP Spaces, Provider Gateways, and Tenant Networking, offering cloud providers and administrators deeper control and customization compared to the Quick Start option—ultimately enabling a flexible, scalable, and secure multi-tenant private cloud environment built on VCF 9.

  • Enhancing Firewall Flexibility in VMware Cloud Director 10.6.1

    With VMware Cloud Director 10.6.1, service providers gain greater flexibility and control over firewall configurations, ensuring compliance with licensing entitlements while delivering scalable, high-value security services. This update aligns with VMware Cloud Foundation (VCF) networking licensing, enabling providers to selectively offer the VMware Advanced Networking & Security (ANS) Add-On to customers based on their needs and cost agreements.

    Impact of VMware NSX Licensing Changes

    Recent changes to VMware’s NSX licensing model have significantly altered how firewall features are provisioned. Under the new structure:

    • Stateless Firewall is included in the VMware Cloud Foundation (VCF)
    • Stateful Firewall now requires an additional, separate license documented Here

    This change impacts how service providers manage network security within VMware Cloud Director environments. To address these shifts, Cloud Director 10.6.1 introduces new controls that give providers flexibility in defining which firewall type—stateless or stateful—is available to their tenants. This ensures security policies align with business needs while optimizing costs associated with VMware licensing.

    VMware Cloud Director with NSX supports both stateful and stateless firewalls, each serving different security needs:

    What is a Stateless Firewall?

    A stateless firewall inspects traffic on a per-packet basis without maintaining the state of active connections. Unlike stateful firewalls, which track the context of traffic flow, stateless firewalls apply predefined rules to each packet independently.

    💡 Key Benefits:
    ✔ Faster packet processing for high-performance workloads.
    ✔ Ideal for perimeter protection and edge security use cases.
    ✔ Lower resource consumption compared to stateful firewalls.

    Stateful vs. Stateless Firewalls in Cloud Director

    FeatureStateful FirewallStateless Firewall
    Connection Tracking✅ Maintains connection state❌ No connection awareness
    Security Context✅ Applies rules based on traffic flow❌ Evaluates each packet independently
    PerformanceHigher resource usageLightweight, optimized for speed

    Configuring in Cloud Director

    This feature is designed to help cloud service providers who wish to control which tenants can access Stateless/Stateful Firewall services. The goal is to enforce better governance over the consumption of advanced network services, such as Stateful Firewall and Distributed Firewall.

    The license selection is made at the Edge Cluster level in VCD. The service provider determines which type of firewall can be applied to a specific Edge Cluster. Consequently, all Provider/Organization and vApp Edge Gateways utilizing that cluster will have firewall rules configured as either stateful or stateless, depending on the selection.

    This will have corresponding changes in NSX, while The firewall rule configuration remains the same in vCD. below is the VMware Cloud Director (VCD) view of the Org VDC Edge Gateway firewall configuration deployed on an Edge Cluster designated with the stateless firewall option inside NSX Manager.

    NOTE : Changing an Edge Cluster from Stateful to Stateless or vice versa will not impact existing deployed Gateways.

    Gateway Firewall Enforcement Control in VCD

    One key use case is when a service provider or tenant is using an appliance-based third-party firewall instead of the NSX-integrated firewall in Cloud Director. In such cases, they may not require NSX-based firewall enforcement and prefer to manage security through their own solution. This feature allows them to disable the NSX firewall, ensuring flexibility in security architecture without unnecessary conflicts.

    Now with this release both service providers and tenants can disable or enable the firewall at the Provider or Org Gateway level without removing existing firewall rules. A new “Active” switch has been introduced in the Firewall UI (top right corner), allowing users to toggle firewall enforcement as needed while preserving the configured rules.

    Conclusion

    The new firewall flexibility in Cloud Director 10.6.1 ensures that service providers can:

    ✅ Optimize licensing costs by choosing stateless or stateful firewall options.
    ✅ Align security offerings with customer needs.
    ✅ Enhance governance and compliance around advanced network security services.
    ✅ Seamlessly integrate third-party firewall solutions into their cloud environments.

    By leveraging these new capabilities, Cloud Director providers can deliver scalable, efficient, and cost-effective security solutions while adapting to the evolving VMware NSX licensing model.

    Cloud Director 10.6.1 Release Notes Published Here

  • VMware Cloud Director OIDC Integration with VMware Workspace ONE Access

    VMware Cloud Director OIDC Integration with VMware Workspace ONE Access

    Prerequisite

    • VMware Workspace access ONE must be already deployed.
    • VMware workspace access ONE must be configured with a directory service source for users and groups.
    • Cloud Director must be installed and configured for provider and tenant organizations.

    Bill of Material

    • VMware Cloud Director 10.5.1
    • VMware Workspace ONE Access 23.09.00

    Steps to Configure Workspace ONE Access for OIDC Authentication

    Workspace ONE Access uses OAuth 2 to enable applications to register with Workspace ONE Access and create secure delegated access to applications. In this case, we will use Cloud Director to integrate with Workspace One Access.

    • In the Workspace ONE Access console Settings > OAuth 2.0 Management page, click ADD CLIENT.
    • In the Add Client page, configure the following.
    LabelDescription
    Access TypeSet to User Access Token
    Client IDEnter a unique client identifier for the Cloud Director Organization (System/Tenant)
    Grant TypeAuthorization Code Grant – When you select Authorization Code Grant, the Redirect URI setting is displayed under Grant Type. Refresh Token Grant – is enabled by default when the Issue refresh token setting is enabled. If you deactivate Issue refresh token, the Refresh Token Grant type is not checked.
    Redirect URIRetrieve this from VCD Provider/Tenant portal at: https://[VCD Endpoint]/(provider or tenant/[orgname])/administration/identity-providers/oidcSettings
    ScopeThe scope defines which part of the user’s account the token can access. The scopes you can select from include Email, Profile, User, NAPPS, OpenID, Group, and Admin.
    Issue refresh tokenTo allow for the return of a refresh token, leave this option enabled.
    Refresh token TTLSet the Refresh Token time to live value. New access tokens can be requested until the refresh token expires.
    Access token TTLThe access token expires in the number of seconds set in Access Token TTL. If Issue Refresh Token is enabled, when the access token expires, the application uses the refresh token to request a new access token.
    Idle Token TTLConfigure how long a refresh token can be idle before it cannot be used again.
    Token TypeFor Workspace ONE Access, the token type is Bearer Token.
    User GrantPrompt users for scope acceptance is disabled. If Enabled users are shown message that lists the scopes that are being sent.
    • Click SAVE. The client page is refreshed and the Client ID and the hidden Shared Secret are displayed.
    • Copy and save the client ID and generated shared secret.
    • Note: If the shared secret is not saved or you lose the secret code, you must generate a new secret, and update in Cloud Director that uses the same shared secret with the regenerated secret. To regenerate a secret, click the client ID that requires a new secret from the OAuth 2.0 Management page and click REGENERATE SECRET.

    Steps to configure VMware Cloud Director to use Workspace ONE Access for Provider/Tenant users and groups

    • From the top navigation bar, select Administration.
    • In the left panel, under Identity Providers, click OIDC or directly you can browse: https:// [VCD Endpoint]/(provider or tenant/[orgname])/administration/identity-providers/oidcSettings
    • If you are configuring OIDC for the first time, copy the client configuration redirect URI and use it to create a client application registration with an identity provider that complies with the OpenID Connect standard, for example, VMware Workspace ONE Access. (this has already been done above)
    • Click Configure
    • Verify that OpenID Connect is active and fill in the Client ID and Client Secret you created in VMware Workspace ONE Access as above during client creation.
    • To use the information from a well-known endpoint to automatically fill in the configuration information, turn on the Configuration Discovery toggle and enter a URL at the site of the provider that VMware Cloud Director can use to send authentication requests to. Fill in the IDP Well-known Configuration Endpoint field with the value:               https://ws01 URL/SAAS/auth/.well-known/openid-configuration
    • Click next.
    • If everything is correctly configured, the below information will automatically get populated, keep a note we are using the User Info endpoint.
    • VMware Cloud Director uses the scopes to authorize access to user details. When a client requests an access token, the scopes define the permissions that this token has to access user information, enter the scope information, and click Next.
    • Since we are using User Info as an access type, map the claims as below and click Next.

    NOTE: At the claims mapping step, the Subject theme will be default populated with “sub” which will mean that VCD users will have the username format “[username]@XXX”. If you want to import the users to VCD with a different format, you can change the Subject theme to map to “email” and then import users to VCD using the email address attached to the account. 

    This is the most critical piece of configuration. Mapping this information is essential for VCD to interpret the token/user information correctly during the login process.

    Login as an OIDC GROUP Member User

    1. In the Provider/Tenant organization’s Administration Page, import OIDC groups and map them to existing VCD roles.
    2. NOTE: In case you don’t see the “IMPORT GROUPS” button, refresh the page, and you will see the desired button IMPORT GROUPS
    • User go to https:// [VCD Endpoint]/(provider or tenant/[orgname])
    • The user should be redirected to the Workspace ONE Access login page. Users can log in with the user in the group.
    • The user will be redirected back to VCD and should now be fully logged in. 

    After the first successful login, the organization administrator can see the newly auto-imported user.

    Login as an OIDC User

    • In the Provider/Tenant organization’s Administration Page, import OIDC users and map them to existing VCD roles.
    • User go to https://[VCD Endpoint]/(provider or tenant/[orgname])
    • The user should be redirected to the Workspace ONE Access login page and log in there.
    • The user will be redirected back to VCD and should now be fully logged in. 

    If you get the SSO Failure page double-check that you imported to the correct group/user and that the username format is correct. For additional information, you can check Here and for troubleshooting and about configuring additional logging, you can check the official documentation here.

    Login without OIDC or as a Local User

    In version 10.5, if an organization in VMware Cloud Director has SAML or OIDC configured, the UI displays only the Sign in with Single Sign-On  option. To log in as a local user, navigate to https://vcloud.example.com/tenant/tenant_name/login or https://vcloud.example.com/provider/login.