What’s new in

WebSphere CloudBurst
1.1?
Authors:
Brian Stelzer, IBM (bsstelze@us.ibm.com)
Dustin Amrhein, IBM (damrhei@us.ibm.com)
 Abstract
The IBM WebSphere CloudBurst Appliance is a revolutionary offering that allows you to
create, manage, and deploy WebSphere Application Server environments in a private
cloud. The first release of this product, version 1.0, introduced capabilities in each phase
of this application environment lifecycle. WebSphere CloudBurst version 1.1 expands on
the initial set of functionality offered by the appliance to introduce broader platform
support, more customization options, new resource sharing capabilities, and enhanced
security controls. In this article, we’ll take a look at the major updates in WebSphere
CloudBurst 1.1 and what those updates mean to you.

WebSphere CloudBurst 1.1

If you are a user or are otherwise familiar with WebSphere CloudBurst 1.0, you know that
it is an appliance offering that is focused on providing you with the capability to create,
deploy, and manage application environments in a private cloud. The appliance is
preloaded with a new version of the WebSphere Application Server called WebSphere
Application Server Hypervisor Edition. You use this virtual image packaging of the
WebSphere Application Server to create complete representations of your WebSphere
application environment. These representations are called WebSphere CloudBurst patterns
and they include your WebSphere Application Server topology as well as custom
configuration such as user applications. Once you have created your patterns, you can use
the appliance to deploy them into the private cloud you have defined, maintain the running
WebSphere Application Server environments created from deployment, and then retire
those environments when necessary.

The newest version of WebSphere CloudBurst, version 1.1, introduces several new
capabilities that enhance WebSphere Cloudburst’s capabilities within the
create/deploy/manage lifecycle. In particular, the new capabilities we will take a look at in
this article include:

1) Support for the PowerVM platform

2) New DB2 Enterprise 9.7 virtual image
3) Integration with VMware vCenter (or VMware Virtual Center)
4) Enhanced customization and management capabilities for application
environments
5) New resource sharing techniques
6) New security controls
7) New LDAP integration capabilities

Let’s drill down into each of these areas to understand the new features you will find in
WebSphere CloudBurst 1.1.
PowerVM Platform Support
A core part of WebSphere CloudBurst is the WebSphere Application Server Hypervisor
Edition. This is a virtual image that contains an operating system, WebSphere Application
Server binaries, WebSphere Application Server profiles, and IBM HTTP Server.

Figure 1. WebSphere Application Server Hypervisor Edition

wca-washv.jpg

All of the software in the image is pre-installed, pre-configured, and the virtual image is
ready to run in a virtualized environment.

Initially in WebSphere CloudBurst 1.0, the WebSphere Application Server Hypervisor

Edition virtual images were packaged solely for the VMware ESX hypervisor platform. In
addition to these VMware images that you can continue to use, WebSphere CloudBurst
1.1 introduces a new version of the WebSphere Application Server Hypervisor Edition
that is packaged for the IBM PowerVM hypervisor platform. This new version, which is
uploaded into the WebSphere CloudBurst catalog alongside the other WebSphere
Application Server Hypervisor Edition versions, of the virtual image includes an AIX
operating system, in place of the SUSE Linux operating system packaged with the
VMware-ready images. Various versions of the image will be provided (as with the
VMware images), including WebSphere Application Server version 6.1.0.27 with and
without feature packs and WebSphere Application Server version 7.0.0.7. The version of
the AIX operating system is 6.1.3 and both the operating system and WebSphere
Application Server are the 64 bit varieties. The new virtual image allows you to build
patterns that can be deployed to the PowerVM hypervisor platform.

In order to allow you to deploy patterns to a PowerVM cloud, WebSphere CloudBurst 1.1
introduces the ability to manage elements of an IBM pSeries environment. To do this,
WebSphere CloudBurst interfaces with a plugin to IBM Systems Director called
VMControl.

Figure 2. WebSphere CloudBurst and the IBM pSeries cloud

wca-pseriescloud.jpg

Figure 2 depicts the way in which the WebSphere CloudBurst Appliance interacts with a
VMControl instance in order to manage the PowerVM cloud environment. Based on
requests from the appliance, VMControl communicates with the Hardware Management
Console (HMC) to create LPARs on IBM Power systems. These LPARs host the virtual
systems that are created as a result of deploying patterns with WebSphere CloudBurst.
VMControl also communicates with a Network Installation Manager (NIM) instance in
order to deploy the WebSphere Application Server Hypervisor Edition virtual images to
the target LPARs. Note that when deploying to a PowerVM cloud you still benefit from
the intelligent virtual machine placement algorithm provided by WebSphere CloudBurst.
Regardless of the type of cloud, WebSphere CloudBurst retains responsibility and control
over virtual machine placement.

You are not constrained to leveraging one cloud type per WebSphere CloudBurst
Appliance. Support for the PowerVM hypervisor platform added in WebSphere
CloudBurst 1.1 means that you can manage both VMware and PowerVM clouds from a
single appliance.

Figure 3. Managing heterogeneous cloud environments

IBM WebSphere CloudBurst Appliance 1.1

The Cloud
Catalog Patterns

VMware
Virtual
hypervisors
images for
VMware Cloud Groups

VMware
Cloud
Group
Virtual PowerVM
images for hypervisors
PowerVM
PowerVM
Cloud
Group

wca-heterocloud.jpg

In order to utilize a PowerVM cloud environment, you need to define a new cloud group.
In the definition of this new cloud group, you specify the location of an IBM VMControl
installation that interfaces with the pSeries environment that includes the PowerVM
platform.
Figure 4. Defining a PowerVM cloud group

wca-pcg1.jpg

In Figure 4, you can see that we provide information about our new cloud group including
its name, hypervisor type, and then the location and login information for the VMControl
instance. In addition to what is shown above, you also supply login information for the
operating system that is hosting the VMControl instance. All that is required for this is a
username and password.

Once the PowerVM cloud has been defined, you can build WebSphere CloudBurst
patterns based on the new version of the WebSphere Application Server Hypervisor
Edition packaged for that environment. The user experience with respect to building
patterns based off this new image is virtually unchanged when compared to building
patterns for VMware platforms. The only difference when building a pattern for the
PowerVM environment is that you select the virtual image built for the PowerVM
platform.
Figure 5. Building a pattern for the PowerVM environment

wca-pvmpattern.jpg

Once the appropriate image is selected, you customize the topology and include script
packages using the same Pattern Editor interface.

In addition to the pattern building process, the pattern deployment process for a PowerVM
pattern is much the same as well. Other than targeting a cloud group that contains
PowerVM hypervisors, the only difference is the option to specify the number of
processors to be assigned to each part in the pattern as highlighted in the image below.
Figure 6. Deploying a pattern to PowerVM

wca-pvmdeploy.jpg

Once a user initiates the deployment process, the appliance intelligently selects the right
hypervisors to host the different virtual machines in the virtual system, and it dynamically
creates LPARs in which the virtual machines will run. Once all the virtual machines and
WebSphere Application Server components within them are started in the LPARs, the
WebSphere CloudBurst Virtual Systems page is updated to reflect the current status.
Figure 7. Virtual system on PowerVM

wca-pvs.jpg

Notice that like virtual systems running on a VMware platform, WebSphere configuration
information, node location information, and links directly into the environment are
supplied.

DB2 Enterprise 9.7 virtual image

The image built for the PowerVM platform is not the only new virtual image delivered
with WebSphere CloudBurst 1.1. The new version of the appliance brings with it a DB2
Enterprise 9.7 virtual image, initially available as a trial offering. The DB2 image resides
in the WebSphere CloudBurst catalog alongside the rest of the WebSphere Application
Server Hypervisor Edition images.
Figure 8. DB2 Enterprise 9.7 virtual image

wca-db2img.jpg

As with all other images, you can use this new DB2 virtual image when building patterns.
To do this, navigate to the Patterns page and click on the green cross at the top of the left
panel. Give your new pattern a unique name, and then select the new DB2 Enterprise 9.7
virtual image as shown in Figure 9.

Figure 9. Creating a DB2 pattern

wca-db2patternpanel.jpg

After selecting the virtual image, click the OK button, and then navigate to the Pattern
Editor by clicking the pencil icon in the upper right hand corner of the screen. Once in the
pattern editor, drag the lone part in the DB2 virtual image and drop it on the pattern
canvas.
Figure 10. Editing a DB2 pattern

wca-db2pedit.jpg

You can optionally include script packages just as you can with other WebSphere
CloudBurst patterns. For instance, you may want to include a script package that creates
and populates databases for your application environment.

Once you are done editing the DB2 pattern, you can deploy it by clicking the Deploy
button on the pattern detail page.
Figure 11. Deploying a DB2 pattern

wca-db2deploy.jpg

Besides the information that is typical to every deployment like virtual machine memory
allocation, CPU allocation, and password information, there is some information particular
to the DB2 environment. First of all, you supply a password for the DB2 instance that will
be created for you. The password you supply, coupled with the pre-configured db2inst1
user, form the credentials you will need to manage the DB2 instance. You can also
provide a custom value for the DB2 Service port and for both the FCM start of port
range and FCM end of port range. Once you supply this configuration information click
the OK button on the part configuration panel and again on the main panel to begin
pattern deployment.

When the pattern deployment process finishes, a process that takes only about three
minutes after the first deployment, you can view information about the DB2 virtual
system.
Figure 12. DB2 virtual system

wca-db2vs.jpg

Once the virtual system is in the started state, you can login to the DB2 instance, via the
link from the WebSphere CloudBurst console if you wish, and manage the database as you
would any other DB2 installation. In addition, your applications can now use this DB2
environment.

VMware vCenter integration

As mentioned above, starting with WebSphere CloudBurst 1.0 and continuing with 1.1,
you can define a cloud that consists of VMware ESX hypervisors. Starting in WebSphere
CloudBurst 1.1, the process of defining this environment is made even simpler by way of
integration with VMware vCenter. When defining a cloud group in WebSphere
CloudBurst you can now specify information about the location of a VMware vCenter
instance as shown in Figure 13.
Figure 13. Adding a VMware vCenter cloud group

wca-virtualcenter.jpg

After you indicate the cloud group is managed by VMware vCenter, you provide the
information about the location of your VMware vCenter instance as well as necessary
login credentials. Once you define the information above and click the Create button, you
will be prompted to accept the SSL certificate from VMware vCenter. After accepting the
certificate, each of the ESX hosts managed by the specified VMware vCenter will show
up in the detail panel for the cloud group.
Figure 14. VMware Virtual Center cloud group details

cb-vmvchvs.jpg

In addition, hypervisor resources were automatically created for each of the hosts shown
in the Hypervisors section above. This means that you do not have to individually add
each of the hosts. Rather, you simply assign IP Groups to the hypervisors and they are
ready to be started. Further, if you do not want to use all of the hosts, you can remove any
of them by simply clicking the remove link. This removes the hypervisor from the cloud
group and deletes the hypervisor resource that was created.

In addition to making it easier to add several VMware ESX hosts, the integration with
VMware vCenter also changes the point of contact between WebSphere CloudBurst and
the hypervisor environment. When you create a cloud group that consists of VMware ESX
hosts that were manually defined, WebSphere CloudBurst communicates directly with
each hypervisor host to initiate deployments and specify the placement of virtual
machines. However, when a cloud group is created that is managed by VMware vCenter,
WebSphere CloudBurst communicates with the VMware vCenter instance directly to
carry out these actions. Regardless of whether or not WebSphere CloudBurst is
communicating directly with VMware ESX hosts or with a VMware vCenter instance, it
always makes the determination of where (which hypervisor) to place the individual
virtual machines in a virtual system. This is done by an intelligent placement algorithm in
the appliance that considers all the compute resources available in a cloud group, and
attempts to optimize performance and avoid single point of failure scenarios for your
application environment.

Currently, WebSphere CloudBurst 1.1 does not support some advanced features offered
by VMware vCenter such as VMotion, Storage VMotion, and Distributed Resource
Scheduling (DRS). If you create a cloud group that is managed by a VMware vCenter
instance, you must make sure that these advanced features are not used on any of the
hypervisors in your cloud group.

Enhanced customization and management capabilities

for application environments
WebSphere CloudBurst is focused on providing the set of capabilities necessary to
manage the full lifecycle of WebSphere application environments in your private cloud.
The ability to create and deploy customized environments, from the operating system
layer all the way up to the middleware layer, and then to update those environments once
they are running in your private cloud is key to supporting the lifecycle. WebSphere
CloudBurst 1.1 introduces enhancements that allow for greater customization of your
application environments, and it delivers updates to the command line interface that allow
you to easily maintain and update these environments in an automated fashion.

Virtual image extend and capture disk resizing

The ability to create a custom image in WebSphere CloudBurst is done through the extend
and capture process. This capability is not new to WebSphere CloudBurst 1.1 as it was
present in version 1.0. However, the ability to resize the four different virtual disks during
the image extension process is new to WebSphere CloudBurst 1.1.

To start the image extension process, navigate to Catalog>Virtual Images and click on
the existing virtual image that you wish to extend. In the upper right hand toolbar, click
the export icon. Figure 15 shows the popup that will appear. In the General information
section enter a unique name and in the Version field enter a version number that makes
sense to you.
Figure 15: Extend/Capture – General information

figure3b.jpg

Next, click on Deployment configuration illustrated in Figure 16. In this view you will
enter the cloud group to deploy the virtual image to and the password used for the “root”
and “virtuser” users. This information is necessary because WebSphere CloudBurst will
create a standard pattern from the image you selected to extend and deploy that pattern
into the cloud group you specify. This provides a running virtual machine in which
customizations, such as installing custom software, can be made.

Figure 16: Extend/Capture – Deployment configuration

figure4b.jpg

Up to this point we did not go through anything new other than the reformatting of
existing options. The truly new part of extend and capture is in the ability to resize the
virtual disks and specify the number of network interfaces. The Hardware configuration
section illustrated in Figure 17 gives you the ability to resize the virtual disks that make
up the virtual image. Once you have extended your virtual image you will be unable to
modify the sizes of the virtual disks.

Figure 17: Extend/Capture – Hardware configuration

figure5b.jpg

The Hardware configuration section shown above is the information that is displayed for
images packaged for the VMware platform. PowerVM virtual images are different in that
they do not contain a separate virtual disk for each component (OS, WebSphere
Application Server binaries, WebSphere Application Server profiles and IHS) of the
virtual image. The PowerVM virtual image is made up of one virtual disk called
image1.mksysb. The default size of this virtual disk is 26GB to which WebSphere
CloudBurst appends 15 additional GBs of storage to accommodate the mksysb filesystem,
resulting in a default total disk size of 41GB. Figure 18 shows the Hardware configuration
for Power.
Figure 18: Extend/Capture – Hardware configuration – Power

figure6b.jpg

Once you have configured your virtual disk sizes press the OK button. This will create a
virtual system with the name you defined in the General information section. The time it
takes for the creation of the virtual system will be in the order similar to a “WebSphere
single server” pattern deployment. Once the virtual system has been created you can
make your modifications and then capture your changes back into the catalog. To capture
your changes you navigate to Catalog>Virtual Images and click on your extended virtual
image. Next, click the capture icon located in upper right corner of the panel. The capture
process will take more time than the extend operation, so be patient.

User initiated script packages

Prior to WebSphere CloudBurst V1.1, script packages attached to a pattern were
automatically invoked by WebSphere CloudBurst near the end of pattern deployment after
the creation of the virtual system. In many cases this was sufficient, but you may also wan
tto attach scripts that are invoked during deletion of the virtual systems or at any time you
decide. There may be times when you want to execute a script package at virtual system
deletion, such as when cleaning up resource handles. There may be times when you want
to execute a script package manually, such as re-installing an application.

WebSphere CloudBurst V1.1 introduced the Executes field on the Cloud>Script

Packages>YOUR_SCRIPT_PACKAGE panel. This field has three options:

 at virtual system creation (default)

 at virtual system deletion
 when I initiate it

at virtual system creation is the default and produces the same script package invocation
behavior that was present in WebSphere CloudBurst 1.0. at virtual system deletion is
just the opposite in that it will happen when the virtual system is deleted. when I initiate
it tells WebSphere CloudBurst that the script package should be invoked when you
specify. Figure 19 illustrates the new field showing the three available options.

Figure 19: “Executes” field

figure1b.jpg

Execution of scripts packages at creation and deletion time is self explanatory, but let’s
take a little closer look at user initiated (when I initiate it) script packages . When you
create a script package and choose when I initiate it, a button will be added to the details
page of the virtual machine on which the script was included as seen in Figure 20.

Figure 20: Virtual system user initiated script package

figure2b.jpg
In order to execute the user initiated script package you click the green play button with
the text Execute now. This will cause WebSphere CloudBurst to transfer the script
package from the catalog over to the virtual machine, unzip and then execute the contents
of the script package. If it is not apparent, this feature allows you repeatedly update your
script package, execute the script package on the virtual machine and verify all without
having to re-deploy the virtual system.

Command line interface updates

The WebSphere CloudBurst V1.1 command-line interface (CLI) brings with it many
enhancements and improvements over the V1.0 implementation. This section will cover
just a few of these enhancements.

Imagine for a second, that the CLI version you downloaded to your local system is at a
different level than the WebSphere CloudBurst appliance you are trying to interface with.
WebSphere CloudBurst V1.1 introduces a feature that will automatically update the CLI
to the correct version. This feature removes the burden of comparing versions,
downloading and installing a matching version of the CLI. The CLI contains a small
amount of bootstrap code that contacts the target appliance, compares versions and if the
versions do not match it downloads the appropriate libraries and uses those to
communicate with appliance. In this way you are ensured that you are always using the
right version of the CLI libraries when connecting to a particular appliance. Figure 21
graphically depicts this process.

Figure 21: Command-line interface automatic update

figure7b.jpg

In addition to this bootstrapping enhancement, there are new features available in the
cloudburst module of the WebSphere CloudBurst CLI.

To start, WebSphere CloudBurst V1.1 CLI comes with support for creating and
manipulating emergency fixes and configuring the appliance. Two resources were
introduced to create and import fixes and maintenance into the catalog:
 cloudburst.fix
 cloudburst.fixes
Four methods were introduced to find and apply fixes and maintenance to the virtual
systems:
 virtualsystem.findUpgrades(…)
 virtualsystem.applyUpgrade(…)
 virtualsystem.findFixes(…)
 virtualsystem.applyFixes(…)

Figure 22 shows an example of an emergency fix being created using the CLI. The first
two lines create an emergency fix with the name Fix-Article and uploads the .pak file.
The last two lines define which virtual image this fix can be applied to (Applicable to
field for those familiar with the UI)

Figure 22: Example - emergency fix creation

figure14b.jpg

After you have created your emergency fix you can install this fix onto a target virtual
system. Figure 23 shows an example of an emergency fix being applied to a virtual
system. The first line gets a handle to the virtual system to which you want to apply the
fix. The second line gets a list of all available fixes for this virtual system. Finally, the
last line applies the fix to the virtual system.

Figure 23: Example – service applied to virtual system

figure15b.jpg

The other improvement in the WebSphere CloudBurst V1.1 CLI is its ability to manage
the appliance settings. The following resources were introduced to allow you to manage
your appliance’s settings:
 cloudburst.security
 cloudburst.ethernet
 cloudburst.dns
 cloudburst.dateandtime
 cloudburst.mail
 cloudburst.ilmt
  cloudburst.firmware
 cloudburst.power

We will not provide examples of all the new CLI capabilities in this article, but you can
find more information about using the WebSphere CloudBurst CLI in the product
information center linked in the Resources section below.

Resource sharing techniques

When you use WebSphere CloudBurst to build customized application environments, you
invest a lot of time and intellectual resource into getting those customizations just right.
You start by creating custom virtual images that contain operating system customizations
like the installation of additional software or other configuration changes, and then based
on these custom images you create customized WebSphere CloudBurst patterns. These
patterns contain not only the different types of nodes that make up your WebSphere
Application Environment but customizations in the form of script packages. These
customizations represent applications, tuning, and other middleware level customizations
that are needed in your particular environment.

Once you have invested the time to build up these customized elements on a particular
WebSphere CloudBurst Appliance, you may want to share them with another appliance.
In WebSphere CloudBurst 1.0 you could do this by backing up the entire state of the
appliance that held your customized images and patterns (the source appliance) to an
external store. Once the backup location was established you could import the appliance’s
state into the WebSphere CloudBurst Appliance that you also wished to have these custom
images and patterns (the target appliance).

This approach is less than desirable when you simply want to share images and patterns
among appliances. In WebSphere CloudBurst 1.1 new capabilities make it easier for you
to share both customized patterns and images among a set of appliances.

Sharing WebSphere CloudBurst patterns

Consider the case that you have built a customized WebSphere CloudBurst pattern on one
appliance and you want to utilize that same pattern, with the same customizations, on a
different appliance. There are essentially three elements that need to be accounted for
when sharing the pattern:

 Pattern (topology)
 Script packages
 Virtual image

All three pieces need to be transferred from one appliance to another in order for this
process to work. We will talk about each in order.
In order to get the pattern off of the appliance you have two options. You can either use
the CLI commands directly or you can use the interactive script that is provided in the
samples directory.

Figure 24 demonstrates using the CLI commands directly. First, you need to get a handle
to the pattern you want to export. Once you have a handle to the desired pattern, call the
.toPython(…) method on the pattern object to export it. The .toPython(…) command
will create a Jython script and place it in the location you specified as a parameter to the
command. As you can see this is pretty simple.

Figure 24: CLI commands to export pattern

figure8b.jpg

WebSphere CloudBurst V1.1 also ships with an interactive script that will accomplish the
same thing as the direct CLI commands in Figure 24. This script is located in the
samples directory and is named patternToPython.py. Figure 25 demonstrates the usage
of this interactive script.

Figure 25: patternToPython.py example

figure9b.jpg
Both the CLI commands and the patternToPython.jy script included in the samples
directory are used to create a Jython script containing CLI instructions to rebuild the
pattern on your target appliance. This script will eventually be executed against the target
environment, but first we must ensure that any associated virtual images and script
packages that make up the pattern exist on the target system.

There is no automated way to export a script package from one appliance to another. You
will need to manually recreate the script package on the target appliance if it does not
already exist on the target appliance. Take note of the script package settings as you will
need these when you recreate on the target appliance.

This may be a good time to point out a best practice when creating script packages.
WebSphere CloudBurst gives you the capability to package the definition of the script
package inside of the archive. This can be done by including a file called cbscript.json
with the script package’s configuration settings. If you use this approach to define your
script packages you can bypass writing down your script package’s configuration settings
and reentering them onto the target appliance. Instead, you just need to upload the archive
onto the target appliance and all of the configuration settings are automatically brought
over. For more information on this approach see part 3 of the Customizing with
WebSphere CloudBurst article series.

To ensure that you have the correct archive contents of the script package click the
Download link which is highlighted in Figure 26.

Figure 26: Script package archive download link

figure10b.jpg

Lastly, you need to ensure that the virtual image that makes up the pattern exists on the
target appliance. If it does not exist then you will need to export from the source
appliance and import into the target appliance.

Exporting virtual images from the catalog

To export a virtual image, navigate to Catalog>Virtual Images and click on the virtual
image that you want to export. Located in the upper right corner is an export icon, click it.
This will result in a window being displayed requesting information on where to place the
exported virtual image (.ova). Figure 27 is a screen capture of the window that is
displayed. The host that you define in the Remote host field must support SCP. Remote
path should be some location that can support a large file transfer. The size of the virtual
image is dependent on your scenario. To give you an idea of the size requirements, the
preloaded virtual images require roughly 4-6GB of storage. The export process can take
some time, which is dependent on the size of the virtual image and the speed of your
network.

Figure 27: Virtual image export dialog

figure11b.jpg

Importing a pattern into the target appliance requires a few steps which we will describe
here. Before you import the pattern, you need to import the virtual image and recreate the
script packages that make up the pattern.

To create a script package in the WebSphere CloudBurst web console, navigate to

Catalog>Script Packages and click on the green plus icon to create a new script package.
Use the archive and information you noted (paying special attention to the name) in a
previous step.

There are two options available when importing a virtual image. You can use the
administrative console by navigating to Catalog>Virtual Images or you can use the CLI.
If you use the administrative console the virtual image that you exported in a previous step
will need to be hosted on a HTTP server. If you use the CLI then you can either push the
virtual image up from a HTTP server or your local file system. Figure 28 shows an
example of the CLI virtual image upload command pushing a virtual image up from your
local file system. The virtual image import operation can take quite some time depending
on the size of the virtual image and speed of your network.

Figure 28: CLI virtual image upload command

figure12b.jpg

At this point you have configured your target appliance with all the pattern dependencies
(virtual image and script packages). The only thing left to do is to import the pattern.
You import the pattern by executing the Jython script created in previous steps. Figure 29
shows how to run the script. As you can see it is no different than executing any other
script.

Figure 29: CLI pattern import command

figure13b.jpg

The pattern and all associated artifacts have been imported into the target appliance. You
can now successfully deploy the pattern.

New Security Controls

WebSphere CloudBurst provides several security features that deliver a secure
environment in which to create, deploy, and manage WebSphere application environments
in a private cloud. A core part of delivering this secure environment is the ability to define
users and user groups with associated set of permissions and resource access rights. In
WebSphere CloudBurst 1.1, updates have been delivered to both user permissions and
resource access rights that help to further enhance security controls in the appliance.

User group permissions

In WebSphere CloudBurst 1.0, the permissions mentioned above were assigned to
individual users of the appliance. User groups were mainly a way to organize users and
assign access to shared resources at the group level instead of having to specify access for
each user in the group. Permissions could not be assigned to user groups.
With updates to WebSphere CloudBurst 1.1 permissions can now be assigned at the group
level. When you define a user group, you will also decide on a set of permissions for the
group.

Figure 30. User group permissions

wca-usergroups.jpg

As you can see, a user group can have the same permissions as an individual user. There
are some things you should know when creating user groups and assigning users now that
permissions are associates with user groups. First, when you add a user to a user group,
any permissions the user had prior to being added to the user group are lost. Users
automatically inherit the permissions of the group to which they are added. As such, once
a user is added to a group (besides the default Everyone group created by the appliance),
that user’s permissions can no longer be edited at the user level. Any permission change
must be done at the user group level. With that said, it is important to point out then that
any permissions granted to a user group apply to all of the users in that particular user
group.

It is possible for WebSphere CloudBurst users to belong to multiple WebSphere

CloudBurst user groups. In that case the effective permissions of the user become the sum
of the permissions of the groups to which the user belongs. For instance, say the user
Dustin belongs to both the Systems Test Group and the Admin Group. The Systems
Test Group has the permission to deploy patterns to the cloud while the Admin Group has
both the cloud and appliance administration permissions. As a result, Dustin would have
permission to deploy patterns, administer the cloud, and administer the appliance.

If at any point a user is removed from a user group, the user retains the permissions of the
groups to which they still belong. From the above example, if Dustin were removed from
the Admin Group he would still have the permission to deploy patterns however he could
no longer administer the appliance or the cloud.

Access control for cloud groups

Suppose you configured multiple different cloud groups that represented different
subclouds within your organization. You may have defined a cloud group that contained
hypervisors used for testing purposes, another cloud group that contained hypervisors used
for development, and yet another cloud group that contained hypervisors used in your
production environment. In this case it is likely that you want to control access to each of
these different subclouds in your WebSphere CloudBurst environment. For instance, you
may want to limit appliance users from your development team to only be able to deploy
their patterns into the development cloud group.

In WebSphere CloudBurst 1.0 access control to different subclouds could only be

controlled by governance policies external to the appliance. There was no way to specify
exactly which users had access to specific cloud groups. However in WebSphere
CloudBurst 1.1, the fine-grained access control previously available for virtual systems,
patterns, virtual images, script packages, and emergency fixes has been extended to cloud
groups. This means that for each cloud group you can decide exactly which users or user
groups have access to deploy patterns into that environment. For example, in Figure 31,
the user Dustin has access to deploy patterns to the Development Cloud cloud group.
Figure 31. Assigning access to cloud groups

wca-cloudgpaccess.jpg

If you are migrating from a previous version of WebSphere CloudBurst to version 1.1 this
new feature will impact cloud groups that existed before the migration in two ways. First,
after migration the owner of the preexisting cloud groups will be automatically set to the
cbadmin user. Any cloud groups created after the migration will be owned by the user
that creates the resource. Second, the user group Everyone is assigned read access to all of
the preexisting cloud groups. This means that all users still have access to deploy patterns
to the cloud groups that were defined in your WebSphere CloudBurst 1.0 setup. This is
done to preserve the access control behavior for cloud groups in WebSphere CloudBurst
1.0.

New LDAP integration capabilities

In many cases you may have an existing LDAP server that contains, among other things, a
record of users, their passwords, and groups they belong to within your enterprise. With
version 1.0 of WebSphere CloudBurst you can integrate with an LDAP server to
authenticate users of the appliance. In this situation, you define users in WebSphere
CloudBurst with the exact same username that appears in your LDAP server. You would
associate permissions with the user in WebSphere CloudBurst, but do not need to provide
a password for the user as is normally done. Instead, when the user logs into the appliance,
the password they supply is authenticated against the information stored in the LDAP
server. This allows you to avoid the situation where a given user’s password is out of sync
across various systems in the enterprise.

With WebSphere CloudBurst 1.1, LDAP integration is extended to the user group level.
Now when you specify an LDAP server you also configure it to integrate with information
about user groups across your enterprise. Once this information is supplied, you can begin
adding both users and user groups to the WebSphere CloudBurst Appliance. When new
users are added to the appliance, they are automatically added to any groups on the
appliance to which they belong. When new user groups are added, any users of the
appliance that are members of the group are automatically added to the new group on the
appliance. When LDAP integration is configured, any time a new user or user group is
added to the appliance, WebSphere CloudBurst verifies that it is a valid user or user group
in your LDAP server. If the user or user group is not defined on the LDAP server it cannot
be added to the appliance.

You should also be aware that when you enable LDAP authentication on the appliance,
group membership can no longer be edited via WebSphere CloudBurst. This means you
cannot add or remove users for a user group on the group’s detail page in WebSphere
CloudBurst, nor can you add or remove groups for a user from the user’s details page.
Any updates to group membership must be done on your LDAP server.

Conclusion
Updates to the WebSphere CloudBurst Appliance delivered in version 1.1 further advance
its capabilities to manage the full lifecycle of WebSphere application environments in a
private cloud. To start, you can now harness the PowerVM platform to host their
virtualized WebSphere Application Server environments. Increased customization and
maintenance controls help you to deliver even more highly customized application
environments all the while providing a more automated approach to maintaining those
environments over time. In addition, WebSphere CloudBurst 1.1 delivers new features
that allow the different elements of these customized application environments to be easily
shared among a set of appliances. Finally, enhanced security controls make it easier to
manage user permissions and control access to subclouds, and new group-level LDAP
integration makes it easier to integrate user and group management between WebSphere
CloudBurst and existing enterprise control systems. You can see some of these new
features in action by viewing the demonstrations on our WebSphereClouds YouTube
channel linked below.