Home > Blogs > Federal Center of Excellence (CoE) Blog > Tag Archives: vcloud automation center

Tag Archives: vcloud automation center

vCAC and it’s Security Capabilities

[originally posted on www.commondenial.com]

I believe that vCAC is one of the ways of putting the “yes” back into innovation versus the “no” that always seems to come out of security people. Innovation is thwarted because we feel like systems are out of our control and when they are, we don’t know what they are doing. We have to ask the network team to give us insight. Now, with vCAC we get the security back because we (the security people) can establish governance and control and sometimes this can bring security.

Governance in itself provides control but by including the ability to require approval, having separation of duties, limiting actions on individual and multi-machine systems, you gain even more control. You have the ability to implement your corporate and IT policies within vCAC and that is superior. The pain with security in the IT realm… yes, in IT, not in the security department is that they don’t want us in there. They feel like we are smothering them. With vCAC, we can take some of that pain away. We now have the ability to work together to develop the right systems to be utilized.

Just one… one of the many examples are the security attributes added to the machines. These actions can be defined on an individual basis. The screen shot below identifies some of the operations available that can be run on the virtual blueprint. As you can see it gives a lot of options and takes away a lot of options.

Now some may think that those options are just plain security and I get that. Truly I do, but this isn’t RBAC, these are operations you can take against the virtual machine. This goes deeper, making the virtual machine(s) the “identity”. You can’t avoid the governance and the control. You can’t ignore the fact that I can provide a limited or great amount of systems, that I have “blessed”, to specific groups of people and allow them to request it themselves. If they want to make the CPU, memory, and/or storage changes, I can provide that. If I want the requests to be approved, I can provide that. If I want to reclaim those machines, I can do that. I feel from a security viewpoint, vCAC can do so much more than people give it credit for. This is how we start bridging the gap between IT and security, this is how we bring them together.

Follow me on twitter @banksek

Use vCloud Automation Center’s Property Dictionary to Customize Service Requests

[originally posted on virtualjad.com]

As I’ve eluded to on more than one occasion, VMware’s vCloud Automation Center (vCAC) is more than just a cloud portal. It is a solution designed to take defined business policy and requirements and apply them to the underlying IT systems, providing a governance model that delivers infrastructure-as-a-service (IaaS) with business agility in mind. Once defined, those policies are applied to vCAC’s individual policy definitions to build a “mesh policy” that provide the governance and controls for self-service, automation, and lifecycle management. The result is a finely-tuned service deployment model that defines the applications (blueprints), where they can be deployed, who can deploy them, and under which circumstances they are (or aren’t) allowed to be deployed. More than just a cloud portal.

vCAC 5.1 provides a ton of this capability “out of the box”, but the solution can also add a tremendous amount of additional capability using built-in control concepts, custom properties, and native integration with external tools such as PowerShell, vCenter Orchestrator (vCO), and others. The possibilities are immense. Those of you who are familiar with vCO will immediately realize the power of that last statement. If you’re not familiar with vCO you should stop reading this, download/deploy the vCO appliance, and make it your best friend…then come back and finish reading. Any workflow available in vCO can be initiated during a vCAC service request. vCAC’s extensibility options — utilizing the built-in Design Center and/or Cloud Development Kit (CDK) add-on — take it to a whole other level of customization and automation. Well-defined use cases and a solid implementation strategy are key when you head down the extensibility path. I will cover more on extensibility and custom use cases in future posts. For now, I’m going to focus on one of vCAC’s built-in concepts that can be used to customize service provisioning options, reduce the number of managed objects (blueprints), and add a nice touch to the user experience…with as few point-and-clicks as possible! What I’m referring to is vCAC’s built-in Property Dictionary feature.

The Property Dictionary

From the vCAC 5.1 What’s New Guide (p. 2-77):

The property dictionary feature, introduced in release 4.5, enables an enterprise administrator to provide a more robust user interface for custom properties that a machine owner enters at request time.

Properties are used throughout the product to provide settings for many features. When users request new machines they are prompted for any required properties. Enterprise administrators or provisioning group managers designate which properties are required by selecting the Prompt User option on the blueprint or build profile. By default, the Confirm Machine Request page displays the literal name of the property as a required text box and does not provide any validation other than that a value has been entered.

The property dictionary allows you define characteristics of properties that are used to tailor the behavior of the request user interface…

(give the “what’s-new” guide a read if you haven’t done so already)

You use the Property Dictionary function to build a Property Definition, which is the logic behind each action. Property definitions can be created for custom properties that require user input during the service request process and, for example, will trigger an external action (e.g. workflow) to complete a given set of tasks that respond back to vCAC when completed. Can you say “Software-Defined Datacenter”?

Some additional uses of the Property Dictionary include:

  • Allowing users to select specific resources that are otherwise hidden (e.g. overriding resource reservation policies to allow users to select a specific datastore, network, or cluster)
  • Creating property names and descriptions that make sense and can be read in plain english
  • Adding pop-up tool tips to explain each required item
  • Customizing the order in which required fields are displayed
  • Making an otherwise required field no longer required

You can also create property definition that utilize vCAC’s built-in reserved custom properties, which can take the user’s input (or selection) and apply that to the existing custom property as an answer file of sorts. For example, you can define a drop-down menu that lists all the networks available to a given Provisioning Group (via that group’s resource reservation) and allow the user to select a preferred network. Once the request is approved, that application is deployed to the selected network. You can also build relationships between parent and child definitions to provide a more dynamic and nested functionality — the user selects a datacenter (“Datacenter A”, parent) and, based on that selection, only appropriate networks (“NetA”, “NetB”, “NetC”, children) become available. The result is an application that gets deployed to Datacenter A using Network B. Throw a storage selection option in there with the same Datacenter relationship rule and now you’ve got a fine balance of policy-based controls and a dynamic user-experience.

Sounds like a good use case to me! — my next post will provide detailed configuration steps for enabling this exact scenario.  Stay tuned…