Community Articles

Find and share helpful community-sourced technical articles.
Announcements
Celebrating as our community reaches 100,000 members! Thank you!
Labels (1)
avatar
Expert Contributor

The preferred method to manage network security with Cloudbreak is to use existing security groups in the target cloud. You manage the security groups in the target cloud's native tools and Cloudbreak adds the nodes to those existing groups.

This allows the access rules in the security group to be centrally managed eliminating the need to propagate changes to existing clusters. Each cluster that gets created will have the same standard access rules, which can be very granular to provide only the access that is required. This also allows separation of the security management duties from the cluster administration duties if an organization requires it.

Network security groups - Microsoft Azure

Each cloud has its own interface for managing security groups. In Azure, for instance, the access rules are in network security groups and each group is available in an individual location. Here we see four network security groups that I've created in Azure's South Central US location for use with Cloudbreak.

I've created these to follow the hostgroups in the blueprint that I'm using. The services that are running on the management master include Ambari, Ambari Metrics and other cluster management tools. They have different access requirements that the namenodes running on the and the security groups reflect those differences.

62732-c63e5222-aabd-4959-bf18-e33798d83915.png

Configuring Existing Security Groups - Hortonworks Cloudbreak

Cloudbreak reads the available security groups from the cloud at the time that the cluster is being configured. In this example, you can see that the same groups created in the Azure dashboard are shown in the existing security groups dropdown list below.

62733-e4288df5-4c71-48f3-b304-7d9239a0bc4e.png

All that is required is to select the proper group for each hostgroup and Cloudbreak will put the VMs it creates into those security groups. Note that in this example I've decided to have one security group for all of the access needed to any services on the master nodes. This will allow services to be moved between master nodes without having to change the groups.

62734-c5256f49-4892-420f-8ec0-8b577fe351e1.png

Once the cluster is built, you can see the VMs that are built.

62736-9c01b982-31f8-40a9-971b-4fe78ebe8b0e.png

Clicking on the VM name will take you to the cloud's interface, allowing you to see the settings that were applied. Clicking on networking shows you the security group being applied.

VM Networking - Microsoft Azure

In the networking section of the VM, you see the Network Security Group that was requested was applied by Cloudbreak.

62737-1e097b0f-311f-4828-a68e-39f0e92dc86c.png

Managing network security groups - Microsoft Azure

Creating a network security group in the native cloud tool is pretty straightforward. Here's what it looks like in Azure:

62738-24a69d57-fe0f-47c8-a22b-7fa3515d4a71.png

Once the Network security group is created, you can define the ports and IP address ranges for access. Changes made here will be effective for any VMs that have already been provisioned as well as any new VMs provisioned to use the same rules.

62739-a1335271-709a-44db-a4df-a60e1fdb21b9.png

888 Views
Version history
Last update:
‎08-17-2019 08:33 AM
Updated by:
Contributors