vCloud Director Federation with IBM Cloud Identity

IBM Cloud Identity is a cloud SaaS Single Sign-On solution supporting multifactor authentication and identity governance. In this article I will describe how to integrate it with vCloud Director, where vCloud Director acts as a service provider and IBM Cloud Identity as an identity provider.

I have already wrote numerous posts how to federate vCloud Director with Microsoft Active Director Federation Service, VMware Identity Manager and vCenter Single Sign-On.  What makes the integration different for IBM Cloud Identity is that it does not accept vCloud Director metadata XML for simple service provider setup and thus the integration requires more steps.

IBM Cloud Identity is a SaaS service and can be for free set up in a few minutes. It is pretty straight forward and I will skip that part.

As usual, in vCloud Director as Organization Administrator we must prepare the organization for federation. It means making sure that in the in the Administration > Settings > Federation the Entity ID is not empty and up-to-date certificate is generated that will be used to trust and secure the SAML2 assertion exchange between IdP and vCloud Director. The vCloud Director autogenerated self-signed certificate has always 1 year validity, which means once a year it must be regenerated (and the IdP reconfigured). The Organization Administrator is alerted via email when the expiration date is approaching. With vCloud API it is possible to provide your own publicly trusted certificate (with possibly longer validity).

Now we can download the metadata XML from the link provided on the same screen. As mentioned above we unfortunately cannot just upload it to IBM Cloud Identity, instead we need to manually retrieve the correct information from the downloaded spring_saml_metadata.xml file.

We will need the federation certificate (<ds:X509Certificate>) saved as properly formated PEM file:
—–BEGIN CERTIFICATE—–

—–END CERTIFICATE—–

Assertion consumer service URL which is in my case: https://vcloud.fojta.com/cloud/org/ibm/saml/SSO/alias/vcd

and entityID – in my case IBM.

Now in IBM Cloud Identity we can set up the application:

  1. Upload the vCloud Director federation certificate in Settings  > Certificates > Add Signer Certificate:
  2. Create new application in Applications > Add > Custom Application and set up General details like Description, icon and Application Owners.
  3. Now in Sign-On submenu we can enter all details we have collected from vCloud Director:
    – Sign-on Method: SAML2.0
    – Provider ID: <EntityID>
    – Assertion Consumer Service URL
    – optionally check Use identity provider initiated single sign-on checkbox and provide Target URL in BASE64 encoded string (in my case I used H5 tenant endpoint URL: https://vcloud.fojta.com/tenant/ibm which base64 encoded translates to: aHR0cHM6Ly92Y2xvdWQuZm9qdGEuY29tL3RlbmFudC9pYm0
    – Service Provider SSO URL (same as Assertion Consumer Service URL)
    – check Sign authentication response and pick Signature Althorithm RSA_SHA256
    – check Validate SAML request signature and pick the certificate from step #1
    – optionally check Encrypt assertion
    – Name Identifier: preferred_username
    – NameID Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

  4. Uncheck: Send all known user attributes in the SAML assertion and instead provide custom list of Attributes to be used. vCloud Director supports the following attributes:
    UserName
    EmailAddress
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
    Groups
    Role
    You can configure the mapping to each. I used preferred_username to be used for vCloud Director username (but alternatively email could be used as well) and did not map Role attribute as I will manage roles in vCloud Director and not leverage Defer to Indentity Provider Role.
  5. Configure Access Policies and Entitlements to specify which users/groups can use vCloud Director.
  6. After saving the application configuration, we can retrieve its SAML2.0 federation metadata from the link provided on the right side of the Sign-On screen.
  7. Back in vCloud Director > Administration > Settings > Federation check Use SAML Identity Provider and upload the downloaded metadata.xml file from the previous step.
  8. Finally we need to import SAML users/groups and assign their role.

If everything done correctly you should be able to login both from IBM Cloud Identity and vCloud Director with the IdP user.

Advertisements

PostgreSQL: Beware of the bloat!

During the last weekend my vCloud Director lab died. And the reason was PostgreSQL DB filled up all the disk space. How could that happen in my small lab with one running vApp?

PostgreSQL database when updating rows actually creates new ones and does not immediately delete the (now dead) old rows. That is done in a separate process called vacuuming.

vCloud Director has one pretty busy table named activity_parameters that is continuously updated. And as you can see from the below screenshot (as reported by pgAdmin table statistics) the table size is 26 MB but it is actually taking 24 GB of hard disk space due to the dead rows.

Another quick way to check DB size via psql CLI is:

\c vcloud
SELECT pg_size_pretty (pg_total_relation_size(‘activity_parameters’));

Vacuuming takes times and therefore it can be tuned in postgresql.conf via a few parameters which VMware documents specifically for vCloud Director here or here. Make sure you apply them (I did not). Another issue that could prevent vacuuming to happen is a stale long running transaction on the table.

The fix:

  • short term: add more disk space
  • long term: make sure postgresql.conf is properly configured
    autovacuum = on
    track_counts = on
    autovacuum_max_workers = 3
    autovacuum_naptime = 1min
    autovacuum_vacuum_cost_limit = 2400
  • manually vacuum the activity_parameters table with the following psql CLI command:
    VACUUM VERBOSE ANALYSE activity_parameters;

And do not forget to monitor free disk space on your PostgreSQL host.

 

Upgrade PostgreSQL version 9 to 10

I had to perform multiple PostgreSQL database upgrades from version 9 to version 10. The database was used for vCloud Director but I believe it is generic enough for other purposes.

The base operating systems I am using is CentOS 7.

Here follows the step-by-step procedure:

  1. Create database backup:
    su – postgres
    pg_dumpall > /tmp/pg9backup
    exit
  2. Shutdown and uninstall old PostgreSQL v9:
    systemctl stop postgresql-9.5.service
    yum remove postgresql*
  3. Archive old datafiles (you will need them later):
    mv /var/lib/pgsql/data/ /data.old
  4. Install new PostgreSQL v10:
    yum -y install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm
    yum -y install postgresql10-server
    systemctl enable postgresql-10
  5. Initiate and start DB:
    su – postgres
    /usr/pgsql-10/bin/initdb
    cp /data.old/pg_hba.conf /var/lib/pgsql/10/data/
    cp /data.old/postgresql.conf /var/lib/pgsql/10/data/
    exit
    systemctl start postgresql-10
  6. Restore backup
    su – postgres
    psql -d postgres -f /tmp/pg9backup
  7. Reboot server. If everything works, you can delete your pg9backup and data.old archive.

Resource Consumption of Org VDC Allocation Types

The reference table below summarizes how different vCloud Director Org VDC allocation types consume vSphere resources. In other words: how a choice of allocation model for a particular Org VDC and its parameters (allocation, guarantees, quota, vCPU speed) translate to resource pool and VM resource settings (CPU/RAM) – reservations and limits.

click for large version

Notes:

  • valid for vCloud Director 9.5 and older (down to 5.5)
  • RP … resource pool
  • Elastic … Org VDC can be divided across multiple RPs across clusters
  • Although there are currently only three Org VDC allocation types the Allocation Pool can be elastic or non-elastic based on vCloud Director instance wide setting in General Settings

IPv6 Support Overview in vCloud Director 9.5

vCloud Director version 9.5 is the first release to provide networking IPv6 support. In this article I want to go into little bit more detail on the level of IPv6 functionality than was in my What’s New in vCloud Director 9.5 post.

IPv6 functionality is mostly driven by the underlying networking platform support which is provided by NSX. The level of IPv6 support in NSX-V is changing from release to release (for example NAT64 feature was introduced in NSX version 6.4). Therefore my feature list assumes the latest NSX 6.4.4 is used.

Additionally it should be noted that vCloud Director 9.5 also supports in very limited way NSX-T. Currently no Layer 3 functionality is supported for NSX-T based Org VDC networks which are imported based on pre-existing logical switches as isolated networks with IPv4 only subnets.

Here is the feature list (vCloud Director 9.5.0.1 and NSX 6.4.4).

Supported:

  • Create External network with IPv6 subnet (provider only). Note: mixing of IPv4 and IPv6 subnets is supported.
  • Create Org VDC network with IPv6 subnet (direct or routed). Note: distributed Org VDC networks are not supported with IPv6
  • Use vCloud Director IPAM (static/manual IPv6 assignments via guest customization)
  • IPv6 (static only) routing via Org VDC Edge Gateway
  • IPv6 firewall rules on Org VDC Edge Gateway or Org VDC Distributed Firewall via IP Sets
  • NAT 64 (IPv6-to-IPv4) on Org VDC Edge Gateway
  • Load balancing on Org VDC Edge Gateway: IPv6 VIP and/or IPv6 pool members

 

Unsupported:

  • DHCP6, SLAAC (RA)
  • Routed vApp networks with IPv6 subnets
  • Isolated Org VDC/vApp networks with IPv6 subnets
  • OSPF v3, IPv6 BGP dynamic routing on Org VDC Edge Gateway
  • Distributed IPv6 Org VDC networks
  • Dual stacking IPv4/IPv6 on OrgVDC networks

 

Experimental/Untested:

  • L2 VPN (tunnel only)
  • SSL VPN (tunnel only)
  • IPSec VPN (tunnel + inner subnets)