On May 25, a critical vulnerability reported which affects vCenter Server 6.5, 6.7 and 7.0 and VMware Cloud Foundation 3.x and 4.x. With access to port 443 of vCenter Server, an attacker may exploit this issue to execute commands with unrestricted privileges on the operating system that hosts vCenter Server. This issue arise because of lack of input validation in vSAN Health Check plug-in.
Before jumping to NSX-T Distributed Firewall (DFW) concept and rule creation, I want to point out why this solution is important and what security issues can be addressed by using this powerful solution. Building a zero trust model security has been the biggest concern of network and security teams. In traditional data centers, high-level segmentation is built, which could help to prevent various types of the workload from communicating. But the main challenge of the legacy security model is data centers facing a lack of lateral prevention communication system between workloads within a tier. In other words, traffic can traverse freely inside a network segment and access the crucial information until it reaches the physical firewall to get dropped. In addition, implementing different layers of security and firewalls would cause complexity and cost.
NSX-T Distributed Firewall (DFW) is a hypervisor kernel-based firewall that monitors all the East-West traffic and could be applied to individual workloads like VM and enforce zero-Trust security model. Micro-segmentation logically divides department or set of applications into security segments and distribute firewalls to each VM.
Continue reading “NSX-T Distributed Firewall – Part 1”After upgrading to vCenter 7 Update 1 , when I tried to browse vCenter HTML5 UI, I faced “no healthy upstream” error. I could access to vCenter Management Interface (VAMI) https://vCenter-IPaddress:5480 without any issues. I could also connect to vCenter Server through SSH but I realized couple of vCenter Server services could not start.
Starting with version 4.7.100, VxRail supports vSAN 2-Node for small and Remote-Office Branch-Office (ROBO) deployments. This solution works best for environments that needs hyperconverged compute and storage with a minimal configuration. VxRail 2-Node consists of two VxRail E560 nodes and a vSAN Witness Appliance. It is recommended to deploy the Witness appliance in another site but in case of lacking another site it can be deployed in the same site as vSAN 2-Node.
There are some considerations and requirements that you need to have it in place before starting the VxRAIL 2-Node implementation.
Continue reading “VxRail 2-Node Implementation Considerations (VxRail 7.0.100)”vSphere 7.0 introduced by VMware in March 2020 and went to GA in April 2020. Many new features like DRS & vMotion improvement and also Lifecycle Manager has been released. After half a year VMware introduced first major update on vSphere 7 and today this release went into GA. It is now publicly available, you can download it from VMware and take advantage of this latest and greatest release! Here in this blog post I will go through the new features and capabilities
One of the new features which has been added to NSX-T 3.0 is supporting RBAC with Native Active Directory. In previous version of NSX-T we had to use VMware Identity Manager (vIDM) to be able to add users and groups from Active Directory for RBAC purposes. In set posts I have already described how to install and configure vIDM with NSX-T. I still believe configuring RBAC through vIDM has some added value like Multi-Factor Authentication(MFA).
To setup NSX-T Role-based Access Control(RBAC) it’s better to create groups in Active Directory and add users into the group for two reasons. First it’s easier to add a group with couple of users as members rather than assign role to many users in NSX-T. Second, with help of Group Policy you can define a “Restricted Group” and it locks down membership to that group. As a result it provides a layer of security.
Continue reading “Configure NSX-T 3.0 RBAC with Native Active Directory Integration”In the previous articles, we deployed first NSX-T Manager and then we added vCenter Server as Compute Manager in NSX-T Web UI. In this post we are going to finalize NSX-T Management cluster. In production environment for high availability and performance reasons, it is recommended to have three NSX-T Managers in the cluster. Second and third NSX-T Managers should be added from NSX-T Web UI. To deploy additional NSX-T manager appliances, go to System menu and choose Appliances and click on “ADD NSX APPLIANCE”.
In previous blog post we started NSX-T implementation by deploying first NSX-T Manager. Before deploying other two NSX-T Managers we need to add a Compute Manager. As it defines by VMware, “A Compute Manager is an application that manage resources such as hosts and VMs. One example is vCenter Server”. We do this because other NSX-T Managers will be deployed through Web UI and with help of vCenter Server. We can add up to 16 vCenter Servers in a NSX-T Management cluster.
To add compute manager in NSX-T, It is recommended to create a service account and customized vSphere Role instead of using NSX-T default admin account. The reason behind defining a specific role is because of security reasons. As you can see in the below screen shot I created a vSphere Role call “NSX-T Compute Manager” with the required privileges. I use this Role to assign permission to the service account on vCenter Server.
Continue reading “Add Compute Manager to NSX-T 3.0”In series of blog posts we are going to walk through different steps to setup a NSX-T Data Center infrastructure. If you are new to NSX-T, please first go ahead and read the Introduction to VMware NSX. To get more insight on NSX-T architecture you can continue with NSX-T Architecture and Components post. Because we are using NSX-T 3.0 for the purpose of this implementation deep dive, you can also review What’s new in NSX-T 3.0 blog post.
Following are the required steps to build a solid NSX-T Data Center foundation. Please follow each step and we are going to update and complete this list regularly.
Continue reading “NSX-T 3.0 Deep Dive”As part of vSAN Stretched or 2-Node cluster configuration, a witness appliance should be deployed and configured. This witness appliance will host witness components that are being used in split-brain failure scenarios. The witness component will act as a tie-breaker and help vSAN cluster to satisfy the quorum requirements. The witness server could be installed as a dedicated physical ESXi host or a specialized virtual witness appliance can be used instead. The main reason for having witness as a virtual appliance is it does not require an extra vSphere license to consume and eventually save some cost especially for smaller implementation like ROBO. The other reason behind using a virtual appliance is for multi-cluster environments like VCF stretched cluster implementation. Due to the reason of each vSAN cluster needs its own witness, then you can consolidate all of them on one physical host on a third site.
