My case study in the clouds…

The title of this post is quite enigmatic, but it touches a very serious problem. How to perform an upgrade of such a complex environment as vSphere with NSX and Trend Micro Deep Security without interruption in ensuring security? The Trend Micro statement says that to perform the upgrade, you must remove the protection, unregister the service, uninstall DSVA, perform the upgrade, re-register in NSX, install DSVA and enable protection. This means a long break in the operation of the environment. Can we resolve this problem in the production system? Fortunately, you can bend this and that and upgrade so that you do not destroy anything by the way. Upgrade Trend Micro Deep Security Management Server to version 11 is quite a simple task and in my opinion there is no point in describing it in detail (just run exe).

In our configuration (as a past after vSphere 5.5) we have a vCenter server with external PSC. When testing vSAN, we decided to join to the VMware CEIP program due to the extension of vSAN cluster monitoring. Unfortunately, the connection turned out to be unsuccessful. After a long search for the cause, it turned out that the error (as usual) is in the certificate. In the virgo log of the vSphere client (flex and html5), the following errors were shown (Server certificate chain is not trusted and thumbprint does not match):

TMP is a system that stores information that allows the authentication of the hardware platform. This information is certificates, passwords and cryptographic keys. There are many applications for this system, for example support for BitLocker in Windows. In the case of vSphere, support for TPM 2.0 appeared in version 6.7 (in the lower versions, e.g. 6.5, the layout of TPM 2.0 will not be visible). Does it affect us and how can we use the TPM 2.0? If our server is equipped with a TPM system that is in UEFI enabled (only UEFI is supported, there is no support in the traditional BIOS) and visible to the server, then an interesting message will appear in ESXi:

One of the main innovations in VMware Integrated Containers 1.3 (VIC) is the extended plugin for vSphere Client UI (html5) with which you can configure and run the VMware Container Host (VCH). This plugin depends on the correct SSL configuration in vCenter. And here the river theme appears, what is the correct configuration? As it turns out, everyone who has generated a certificate from VMCA signed by Root CA (aka custom certificate) has an almost good configuration. Where the problem arises, I will describe below.

About Trend Micro Deep Security on this blog I wrote many times, but I have not mentioned yet one of the features of this solution, ie SSL traffic inspection. According to recent Google statistics, more than 70% of network traffic is already encrypted. This means that all IDS/IPS/WAF solutions that can not sniff SSL traffic and inspect it are immune to attacks! For Deep Security, we have the ability to enable SSL inspection at the Intrusion Prevention module level. Of course, we will not achieve such efficiency and effectiveness as in the case of BIG-IP F5 , but we will clearly increase the level of security of the protected services.

For how to install and configure vSphere Integrated Containers I recently wrote here. Today we will create our own base docker image (with CentOS 7 system) with any application, and load it into the registry (image repository) on Harbor. In addition, we will create a persistent volume that will connect to our new container. The topic of VIC is quite new, so there is not much information on the Internet related to it, this article was created as an attempt to systematize the knowledge associated with it.