Security Overview
Cloudbreak utilizes cloud provider security resources such as virtual networks, security groups, and identity and access management:
- Network isolation is achieved via user-configured virtual networks and subnets.
Read more about Virtual Networks. - Network security is achieved via out-of-the-box security group settings.
Read more about Network Security. - 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 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:
-
Interactive: The app and service principal creation and role assignment are fully automated, so the only input that you need to provide to Cloudbreak is your Subscription ID and Directory ID.
-
App-based: The app and service principal creation and role assignment are not automated You must create an Azure Active Directory application registration and then provide its parameters to Cloudbreak, in addition to providing your Subscription ID and Directory ID.
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