Security Overview

Cloudbreak utilizes cloud provider security resources such as virtual networks, security groups, and identity and access management:

  1. Network isolation is achieved via user-configured virtual networks and subnets.
    Read more about Virtual Networks.
  2. Network security is achieved via out-of-the-box security group settings.
    Read more about Network Security.
  3. Controlled use of cloud resources using IAM roles (AWS, GCP) or Active Directory (in case of Azure). Read more about Identity Management.

Virtual Networks

Cloud providers use virtual networks which resemble traditional networks. Depending on the options that you selected during deployment, your Cloudbreak instance and clusters are launched into new or existing cloud provider networking infrastructure (virtual networks and subnets). For more information about virtual networks, refer to the cloud-provider documentation:

Cloud Provider Documentation Link
AWS Amazon Virtual Private Cloud (Amazon VPC)
Azure Microsoft Azure Virtual Network
Google Cloud Platform Virtual Private Cloud (VPC) network
OpenStack Network

Network Security

Security groups are set up to control network traffic to the instances in the system.

Cloudbreak uses public IP addresses when communicating with cluster nodes. On AWS, you can configure it to use private IPs instead. For instructions, refer to Configure Communication via Private IPs on AWS.

Cloudbreak Instance Security Group

The following table lists the minimum security group port configuration required for the Cloudbreak instance:

Inbound Port Description
22 SSH access to the Cloudbreak VM.
80 HTTP access to the Cloudbreak UI. This is automatically redirected to the HTTPS (443) port.
443 HTTPS access to the Cloudbreak UI.

Default Cluster Security Groups

For clusters, Cloudbreak provides the following security group settings. If you do not modify these settings, these default security rules will be created. You can modify these rules either when creating or, if you don't want to use security group, remove them.

As an alternative to creating new security groups, you can select from your existing set of security groups, which can be modified using the cloud provider tools.

Cluster Host Group with Ambari Server

Inbound Port Description
22 SSH access to the VM instance. This port is also used by Cloudbreak to communicate with the cluster.
443 HTTPS access to the Ambari UI.
9443 Management port, used by Cloudbreak to communicate with the cluster node VM.

Important

By default, ports 22, 443, and 9443 are set to 0.0.0.0/0 CIDR for inbound access on the Ambari node security group. We strongly recommend that you limit this CIDR, considering the following restrictions:

  • Ports 22 and 9443 must be open to Cloudbreak's CIDR. You can set CB_DEFAULT_GATEWAY_CIDR in your Cloudbreak's Profile file in order to automatically open ports 22 and 9443 to your Cloudbreak IP. Refer to Restricting Inbound Access from Cloudbreak to Cluster.
  • Port 22 must be open to your CIDR if you would like to access the master node via SSH.
  • Port 443 must be open to your CIDR if you would like to access Ambari web UI in a browser.

Cluster Host Groups without the Ambari Server

Inbound Port Description
22 SSH access to the VM instance.

Important

By default, port 22 is set to 0.0.0.0/0 CIDR for inbound access on non-Ambari node security groups. We strongly recommend that you remove it.

When creating a new security group, Cloudbreak uses the following naming convention: <clustername>-ClusterNodeSecurityGroup<hostgroupname>

Identity Management

To securely control access to cloud resources, cloud providers use identity management services such as IAM roles (AWS and GCP) and Active Directory (Azure).

Cloud Provider Documentation Link
AWS AWS Identity and Access Management (IAM)
Azure Azure Active Directory ((Azure AD))
Google Google Cloud Identity and Access Management (IAM)
OpenStack Keystone

Cloudbreak utilizes cloud provider’s identity management services via Cloudbreak credential. After launching Cloudbreak on your chosen cloud provider, you must create a Cloudbreak credential, which allows Cloudbreak to authenticate with your cloud provider identity management service. Only after you have completed this step, Cloudbreak can create resources on your behalf.

Authentication with AWS

When launching Cloudbreak on AWS, you must select a way for Cloudbreak to authenticate with your AWS account and create resources on your behalf. While key-based authentication uses your AWS access key and secret key, role-based authentication uses IAM roles.

If you are using role-based authentication for Cloudbreak on AWS, you must create two IAM roles: one to grant Cloudbreak access to allow Cloudbreak to assume AWS roles (using the "AssumeRole" policy) and the second one to provide Cloudbreak with the capabilities required for cluster creation (using the "cb-policy" policy).

The following table provides contextual information about the two roles required:

Role Purpose Overview of Steps Configuration
CloudbreakRole Allows Cloudbreak to assume other IAM roles - specifically the CredentialRole. Create a role called "CloudbreakRole" and attach the "AssumeRole" policy. The "AssumeRole" policy definition and steps for creating the CloudbreakRole are provided below.

When launching your Cloudbreak VM, during Step 3: Configure Instance Details > IAM, you will attach the "CloudbreakRole" IAM role to the VM.

CredentialRole Allows Cloudbreak to create AWS resources required for clusters.

Create a new IAM role called "CredentialRole" and attach the "cb-policy" policy to it. The "cb-policy" policy definition and steps for creating the CredentialRole are provided below.

When creating this role using the AWS Console, make sure that that it is a role for cross-account access and that the trust-relation is set up as follows: 'Account ID' is your own 12-digit AWS account ID and 'External ID' is “provision-ambari”. See steps below.

Once you log in to the Cloudbreak UI and are ready to create clusters, you will use this role to create the Cloudbreak credential.

Related Links
Meet the Prerequisites: Authentication

Authentication with Azure

After launching Cloudbread on Azure, you are required to create a Cloudbreak credential, which allows Cloudbreak to authenticate with your Azure Active Directory.

You have two options:

Related Links
Create Cloudbreak Credential

Authentication with GCP

After launching Cloudbreak on GCP, you are required to register a service account in Cloudbreak via creating a Cloudbreak credential. Cloudbreak uses this account to authenticate with the GCP identity management service.

Related Links
Meet the Prerequisites: Service Account

Authentication with OpenStack

After launching Cloudbreak on OpenStack, you are required to create a Cloudbreak credential, which allows Cloudbreak to authenticate with keystone.

Related Links
Create Cloudbreak Credential