1. Customer access
Contents
To avoid customer confusion, we recommend disabling the extension globally, post deployment, and only exposing the extension to customers who are subscribing to the service. This is an API driven process that is broken down into four key steps. I will not go into detail, as I have written a blog that walks you through the steps to manage the extension. For more information on managing the extension, please check out this blog
In vCloud Director 9.7, extensions are managed via the plugin manager. To get to the plugin manager, navigate to Main Menu → Customize Portal → Manage Plugins. Once in the plugin manager, you will see all of the loaded plugins and how they are scoped.
In our particular instance, you will see that the vCloud Availability extension is scoped for both the provider and the tenant. What we need to validate is which tenants it has been scoped for. To see, and edit, which tenants have access to the Availability plugin, click the checkbox next to vCloud Availability and select the Publish option in the menu across the top. This will pop up a modal that will allow you to select where to publish the extension. By default, the extension will be set to publish to all tenants. You will want to click on this box to disable it globally and select on the tenants you want to have access to the service. Once you have selected the appropriate tenants, click Save.
2. Certificates
Before we dig into the process for updating certificates, it is important to understand what role they play. When we talk about vCloud Availability, the service is really comprised of three appliances: the Cloud Manager, the Replicator, and the Tunnel. Certificates play a crucial role in the appliances. Not only are they used for the management interface, they also use for host validation when communicating. This is important to understand as it will have an impact on your approach to certificate management. The first inclination is to replace all certificates on all hosts. This is acceptable if you are using host specific certs on each of the appliances. Where the problem lies, is when you try to use the same key and certificate (i.e. wildcard certificate) on all of the hosts. Because the certificates are not only used for the management interface, but also the communication between the hosts, using the same wildcard cert causes failures. Since customers only interact with the Cloud Manager, this is the only certificate that needs to be replaced by a publicly signed certificate. Since the certificates for the tunnel and replicator are used for the communication chain and management interface which are only accessible via the provider, the need to change these certificates is dictated by company policy.
But wait, doesn’t the user interface with the tunnel? And doesn’t that mean it will need a publicly signed certificate as well? Yes and No. This can get a little confusing, so let me try to do my best to explain. When setting up the on-premises appliance, the tenant will provide the hostname or IP address of tunnel. But, when the user actually connections, what the user will see is the certificate coming from the Cloud Manager, not the tunnel.
Example values:
Common Name: vcav.provider.net
Organization: Provider
Fingerprint: SHA256 Fingerprint=7D:C3:BA:76:16:D1:1B:43:A8:CD:AF:82:87:6D:28:42:E1:0E:98:5C:7F:4F:97:5C:16:38:89:25:B1:08:4A:7E
The tunnel is not only providing the encryption layer between the two sites, but it is also behaving as a TCP proxy. So, as requests come across, the tunnel will forward the request to the appropriate resource. (i.e. replication traffic will be forwarded to the replicators and management traffic will be forwarded to to the Cloud Manager). Since the tunnel is also a proxy for the Cloud Manager, this is why the only required public certificate needs to be placed on the Cloud Manager.
Now that is clear as mud, let’s talk about how to update the certificate on the Cloud Manager. There is a lot of documentation out there on generating keys and certificate signing requests (CSRs) and depending on your company policy, you may have different requirements. As I walk through this process, I won’t go too in-depth, but I will try to call out certain options which can be problematic, such as subject alternative names (SAN). Although SANs are not required for a valid certificate, in an environment such as ours where the internal hostname may not match the publicly accessible hostname, using SAN will help ensure the certificate passes validity tests. Also, certain browsers, such a Google Chrome, are starting to require SANs to be marked as valid certificates.
2.1. Generate certificate signing request
To create a certificate for the Cloud Manager, The first thing you will want to do is generate a key and certificate signing request for the host. To do this, you will need a machine running openssl. Although a subject alternative name is not a requirement for the certificate to have the value applied, it is best practice to provide all pertinent information to your certificate authority. Because of this, we will create a configuration file called req.conf with the following information:
|
|
Once this file has been created, we will create a private key and certificate signing request in one step with the following command:
|
|
|
Once you have generated your signing request you may want to review it. To view your csr, use the following command: |
|
|
Once you have validated your CSR and everything looks good, submit your CSR to your certificate authority.
2.2. Validate certificate
Once you have received the certificate back from the certificate authority, the next thing you will want to do is validate the certificate and ensure the Subject Alternative Names have been appropriately configured. To view the certificate in plain text, run the following command:
|
|
In running this command, the certificate will be output in plain text and you should see a X509v3 Subject Alternative Name field with all of the provided values in the CSR.
2.3. Converting the certificate
Most certificates will be provide back to you as a .pem or .crt file. vCloud Availability is using a Java keystore so it you will need to convert this certificate to a pksc12 format. Doing this is really simple. Upload the certificate to the same directory where you generated your private key and csr. Once uploaded, run the following:
|
|
This will create the certificate bundle necessary to upload to the cloud manager. It is also important to provide a password when generating this file in order to protect your private key.
2.4. Uploading
The final step is to upload the certificate bundle to the Cloud Manager. First ensure the certificate bundle is located on the same machine you will be using to configure the Cloud Manager. Next, log into the Cloud Manger at https://<cloud manager>/ui/admin and navigate to Configuration → Appliance Settings → Certificate. Once there, click import. A modal will pop up allowing you to import your certificate bundle.
The password will be the password you assigned in the previous step. Click browse and locate the certificate bundle. Once complete click apply. After doing this, you will be logged out and the service restarted. After a few minutes, you will be able to log back in with the newly applied certificate.
3. Remote administration
In vCloud Availability 3.0.1 a new security feature was added that restricts the source address that exercise certain API endpoints. If this feature is enabled, which is recommended, other cloud sites won’t be able to run pairing, or repairing, operations for the given site.
4. Default policies
As new tenants are provisioned they are assigned to the default policy. Out of the box, the default policy is set to prohibit replications in either direction. If a user is tenant is assigned to a policy that does not allow for replication in either direction, they will not be able to pair their on-prem appliance with the service and will receive a resulting error. As a default behavior, this isn’t necessarily a bad idea, it is just important to be aware of.
As a result, it will be important to have at least one policy in place that allows for replication post deployment. To create a new policy, Navigate to Policies in the left navigation menu and select New. This will pop up a modal that will allow you to define the details of the policy. These can be leveraged to on a tenant by tenat basis, or can be be defined based on a tiering structure (Gold, Silver, Bronze, etc). The values that are defined will be the smallest values that can be set by the tenant.
As an example, if we set a policy that allows for 10 retained instances, and a 30 minute RPO, a tenant assigned to the policy will not be able to configure more than 10 instances for a given VM/vAPP, but can configure less (i.e. five retained instances) and the minimum RPO will be 30 minutes or more (i.e. two hours).
It is also important to note that only one policy can be assigned to a tenant.
5. Post deployment – Conclusion
Now that the provider environment has been deployed and configured, in our next blog, we will focus on deploying the tenant appliance and pairing to provider
Please feel free to review other articles related to the vCloud Availability blogs series:
1. vCloud Availability 3.0 Blog Series: Introduction
2. vCloud Availability 3.0 Blog Series: Provider Installation
3. vCloud Availability 3.0 Blog Series: Provider Post Deployment Configuration
4. vCloud Availability 3.0 Blog Series: Tenant Installation
5. vCloud Availability 3.0 Blog Series: Tenant Post Deployment Configuration
6. vCloud Availability 3.0 Blog Series: Managing vCloud Availability Access
7. vCloud Availability 3.0 Blog Series: Cloud Access, Ownership, and Visibility
