Governing the Cloud with CloudForms

Overview

In a previous article it was stated that cloud in not a technology but rather an architectural methodology of resource governance that utilizes underlying virtualization technologies. Since cloud is more about the methodology, the technology platforms such as VMware vCenter, Red Hat Virtualization Management (RHEVM), Microsoft System Center, Amazon EC2 and OpenStack can change as application requirements or life cycles change. An application may start on a virtualization platform like VMware but over time move to a cloud platform such as OpenStack. It could even have components serviced by both. This is the exact concept behind what Gartner talks about when they refer to Bi-Modal IT. Gartner also says 50% of companies will screw this up. A bridge is definitely needed for managing applications between these various platforms. Red Hat CloudForms is exactly that bridge. It allows us to create an abstraction above the virtualization platforms so that governance and business process can remain consistent across the cloud.
In this article we will take a look at how to setup governance of cloud resources using CloudForms. If you are new to CloudForms I would suggest reading this article to get a proper introduction.

Before we get into creating policies that define resource governance in the cloud, we need to enable a few advanced features in CloudForms. "Capacity and Utilization" is needed for more detailed reporting and "SmartState Analysis" is required to get visibility inside virtual machines.

Configure Capcity and Utilization

CloudForms connects to infrastructure or cloud providers in order to report capacity and utilization. Therefore it is important to ensure the provider itself is collecting and reporting information. In this case we will configure Red Hat Enterprise Virtualization Management (RHEVM) provider to display capacity and utilization in CloudForms. Some steps are of course provider specific, in this case RHEVM specific.

Configure RHEVM

In RHEVM we need to configure reporting database user and allow remote access to the database.

#psql -U postgres CREATE ROLE newuser LOGIN UNENCRYPTED PASSWORD 'newuserpassword' SUPERUSER VALID UNTIL 'infinity'; \q

#iptables -I INPUT -p tcp -m tcp --dport 5432 -j ACCEPT
#service  iptables  save

#vi /var/lib/pgsql/data/pg_hba.conf
host    all      all    0.0.0.0/0     md5

#vi /var/lib/pgsql/data/postgresql.conf
listen_addresses  =  '*'

#service  postgresql  reload

Configure CloudForms

Once our reporting user and provider database is configured it is time to enable capacity and utilization in CloudForms.

Ensure all server roles are enabled except "Database Synchronization" and "RHN Mirror".

 

Under "Configure->Configure" set the capacity and utilization policy for the CloudForms region. In this case we will enable all clusters and datastores.

Configure Smart State Analysis

SmartState analysis allows us to look inside virtual machines. CloudForms does this by mounting datastores and peering inside the virtual disks. CloudForms is able to see user accounts, installed packages and configuration files for given virtual machine. This data enables us to create resource governance policies as you will see later.

Under "Configuration->Configuration->Settings" edit the zone and enter IP of the CloudForms appliance you want to act as smart proxy. This is the system that will mount and connect to virtual machines for SmartState analysis. As such the CloudForms appliance requires access to shared storage used for datastores.

Finally the last step is to make CloudForms aware of what virtual machines are hosting CloudForm appliances. Under "Infrastructure->Virtual Machines" select appropriate virtual machine and edit management engine relationship. You can then match the virtual machine with the appropriate CloudForms engine. Note: this is new in CloudForms 3.2. Previously you would configure this under "Configure->Configure->Smart Proxies".

At this point we have configured both capacity and utilization in addition to SmartState analysis. You can now gather SmartState information about hosts and virtual machine by selecting "Perform SmartState Analysis" under configuration of host or virtual machine. Ideally you would create a schedule that runs the SmartState analysis on a regular interval for all hosts and virtual machines. You could also however create a control policy that runs SmartState analysis whenever hosts or virtual machines are started.

Governance Policies

CloudForms has two types of governance policies: compliance and control. Compliance policies are scheduled or run manually and check the compliance state of hosts or virtual machines. If a host or virtual machine is found out of compliance an action can be taken. Control policies differ only slightly in that a control policy is run based on an event occurring, so these are automated policies based on events where compliance policies are manually operated or scheduled via the administrator.

This may be a bit confusing at first but let me give an example. Lets suppose you want to protect against a known security vulnerability in virtual machines. You have two options and the only difference really is when do you check for vulnerability? If you check at a given time decided by administrator you would create compliance policy. If you check based on event happening like the virtual machine starting you would create a control policy.

CloudForms Terminology

Below is terminology relating to policies in CloudForms:

Policy Profile - Grouping of policies that can be applied to hosts or virtual machines.

Policy - Defines conditions and actions. Can be triggered by user in case of compliance policy or event in case of control policy.

Condition - Tests for a desired or non-desired state. Can be true or false. Conditions are used to trigger actions.

Action - Triggered based on condition matching true or false.

Event - Only relating to control policy, this is what triggers the control policy to execute.

Create Compliance Policy

In this example we will create a compliance policy that checks if the firewall is disabled on hypervisor hosts. If the firewall is disabled the condition would be true and an action will set those hosts to non-compliant.

Under "Control->Explorer" select the policies accordion. Create a new policy called "Check Firewall".

Next select the policy and add a new condition. Conditions allow us to check for state, in this case the state being that the firewall is disabled. You can have multiple conditions in an expression but in this example we just need one. Select field and "Host / Node.OS:Firewall Rules Active". Select false which means if the firewall is not active, the condition is true. Click the check mark to add the condition to the expression box.

The condition should now appear in the expression box and can now be saved.

Next we need to create a policy profile. This is simply a grouping of policies that we can apply to a host or virtual machine. In "Control->Explorer" select the policy profile accordion and under configuration dropdown add a new policy profile. You can give it a name "RHEV Hypervisor" and add policies by moving them from left to right.

Once we have a policy profile defined we can add it to the hypervisor hosts. Under "Infrastructure->Hosts" select the hosts and under policy dropdown select manage policies.

Now we can enable policy profiles on the selected hosts.

We can test the compliance policy by selecting the "check compliance of last known configuration" option from the host policy dropdown. When clicking on the host we can see if it is compliant under the compliance section.

In this case our host is not compliant because the firewall is disabled.

# systemctl status iptables
iptables.service - IPv4 firewall with iptables
 Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled)
 Active: inactive (dead)

Create Control Policy

As mentioned control policies are not that much different than compliance policies, they are simply driven from events. In this example we will do same check to see if firewall is enabled, only this time with control policy. Everytime a host is started and connected we will check if firewall is disabled. If the firewall is disabled we will have an action write to the audit log. Again both control and compliance policies can do same actions only difference is the trigger, in this case an event.

Under "Control->Explore" policies accordion select control policy and create a new control policy for host.

Since we are using the same condition to check if firewall is disabled we can simply edit condition and select the condition we already created. All policies can leverage same conditions.

Next we need to tell CloudForms what event will drive the policy into action. Select the policy and under the configuration dropdown "edit policy event assignments". In this example our event is the starting of a host.

Under "Host Connect" event we can add an action. In this case to generate an audit log message. Under configuration dropdown select "edit action for this policy event". Select "generate audit event" if the conditions are true, meaning the firewall is in fact disabled.

Finally under "Control-Explore" policy profile accordion we can add our new control policy to the existing profile policy "RHEV Hypervisor".

In order to test the control policy I can simply restart a host. Once host is restarted the control policy will automatically run and if the firewall is disabled an event will be written in the audit log. The audit log can be viewed under "Configure->Configure" diagnostics accordion.

[2015-07-12T00:01:31.139400 #6530:af7ea4]  INFO -- Success: MIQ(PolicyProfiles.profile_edit) userid: [admin] - [11fe79f2-2815-11e5-9d99-001a4aa04b00] Record updated (policies:[{"Host / Node Compliance: Check Firewall"=>1000000000003}] to [{"Host / Node Compliance: Check Firewall"=>1000000000003, "Host / Node Control: Generate Audit Event for Firewall"=>1000000000006}]) 

Conclusion

In this article we have seen how to use Red Hat CloudForms to create both compliance and control policies that can govern our cloud infrastructure. Regardless of if your cloud consists of VMware vCenter, RHEV, Microsoft Systems Center, Amazon EC2 or even OpenStack common policies that define cloud governance can rule them all. The true power of CloudForms is allowing cloud administrators to build an abstraction layer around virtualization platforms that enables cloud governance. Regardless of what virtualization platform one uses, the policies should remain constant across all infrastructure. This is truly the only way to govern a cloud and create a standard operating environment. Hopefully you have found the information and topic discussed in this article informative. This is only of course the tip of the iceberg, but if it has gained your interest, I certainly implore you to consider looking into cloud management with CloudForms.

Happy cloud governance and rest easy with CloudForms!

(c) 2015 Keith Tenzer