This article discusses prerequisites required for Cloudbreak credential and addresses common issues. This article applies to Cloudbreak 2.4.0.
When getting started with Cloudbreak, the most common pain point is creating the Cloudbreak credential, or - more precisely - meeting the prerequisites for the Cloudbreak credential.
Why do you even need this Cloudbreak credential? Cloudbreak not only runs on your cloud provider account, but once you start using, it provisions resources (such as VMs) that run as part of your account and that you or your organization must pay for. Cloudbreak credential provides the means for Cloudbreak to authenticate with your cloud provider account and provision such resources.
The exact details vary depending on the cloud provider:
- On Azure this is typically done by creating an app registration in Azure Active Directory and providing its details to Cloudbreak.
- On AWS this typically happens by assigning a proper IAM role to Cloudbreak. Cloudbreak can assume this role in order to create resources on your behalf.
- On Google Cloud this is typically done by creating a Service Account that Cloudbreak can use to create resources.
Azure Credential
There are two ways in which Cloudbreak can access your Azure account: interactive and app-based.
Interactive
The first way is via the interactive credential, where Cloudbreak automated the app and service principal creation and role assignment, so the only input that you need to provide is the Subscription ID and Directory ID. You can definitely use this if you are evaluating Cloudbreak by deploying it on your own Azure account. However, if you are using a corporate account, you will most likely be unable to use the interactive credential at all, because your account must have the "Owner" role (or its equivalent) in order for Cloudbreak to perform the interactive credential creation steps. The error that you will get will be:
You don't have enough permissions to assign roles, please contact your administrator
Also - just to throw it up there - when using this method, you must be able log in to your Azure account.
> This is true for Cloudbreak 2.4.0, but may change in future releases.
App-based
If you do not meet the requirements for using the interactive credential, you are left with the second option, which is the app-based credential. The advantage of the app-based credential creation is that it allows you to create a credential without logging in to the Azure account, as long as you have been given all the required information. You must provide your Subscription ID and Directory ID (called “Tenant ID” in Cloudbreak UI), you must provide information for your previously created Azure AD application (its ID and key which allows access to it).
One tip here is that after registering an Azure application you may have to ask your Azure administrator to perform the step of assigning the "Contributor" role to it:
Your account will most likely not have the required permissions and you will get an error. Once your Azure admin performed the role assignment, you can perform the create credential task in Cloudbreak.
Related docs:
Create Cloudbreak Credential on Azure
AWS Credential
On AWS, there are two ways for Cloudbreak to authenticate with your AWS account and create resources on your behalf: key-based credential and role-based credential.
Key-based
To use this, you must be able to provide your AWS access key and secret key pair. If you don’t have these, you may be able to generate a new access and secret key pair from the IAM Console > Users.
If you are able to generate these, then this is the easiest way to get started. However, when using a corporate account, you may want to or you may have to use the more complicated role-based credential.
Role-based
Role-based credential utilizes IAM (Identity Access Management) roles. There are two IAM roles involved:
- When launching Cloudbreak, you are required to provide an IAM role with AssumeRole policy assigned. The AssumeRole allows Cloudbreak to use the CredentialRole described in the next bullet.
- After Cloudbreak is running, when you create a Cloudbreak credential, you must provide an IAM Role ARN for another IAM role (which is called CredentialRole in the documentation). This role provides a set of permissions required for provisioning resources.
If you chose (or were forced to choose) this approach, you may need to contact your AWS admin to help you out, as you may not be able to create IAM roles.
Another tip is that you should make sure to include all the permissions mentioned in the CredentialRole policy definition. If you miss some of them, you will get an access-related error when creating a cluster.
Reference:
AssumeRole policy definition for Cloudbreak:
{
"Version": "2012-10-17",
"Statement": {
"Sid": "Stmt1400068149000",
"Effect": "Allow",
"Action": ["sts:AssumeRole"],
"Resource": "*"
}
}Policy definition required for Cloudbreak credential:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:DescribeStackEvents",
"cloudformation:DescribeStackResource",
"cloudformation:DescribeStacks"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:AllocateAddress",
"ec2:AssociateAddress",
"ec2:AssociateRouteTable",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DescribeRegions",
"ec2:DescribeAvailabilityZones",
"ec2:CreateRoute",
"ec2:CreateRouteTable",
"ec2:CreateSecurityGroup",
"ec2:CreateSubnet",
"ec2:CreateTags",
"ec2:CreateVpc",
"ec2:ModifyVpcAttribute",
"ec2:DeleteSubnet",
"ec2:CreateInternetGateway",
"ec2:CreateKeyPair",
"ec2:DisassociateAddress",
"ec2:DisassociateRouteTable",
"ec2:ModifySubnetAttribute",
"ec2:ReleaseAddress",
"ec2:DescribeAddresses",
"ec2:DescribeImages",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstances",
"ec2:DescribeInternetGateways",
"ec2:DescribeKeyPairs",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSpotInstanceRequests",
"ec2:DescribeVpcAttribute",
"ec2:ImportKeyPair",
"ec2:AttachInternetGateway",
"ec2:DeleteVpc",
"ec2:DeleteSecurityGroup",
"ec2:DeleteRouteTable",
"ec2:DeleteInternetGateway",
"ec2:DeleteRouteTable",
"ec2:DeleteRoute",
"ec2:DetachInternetGateway",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:ListRolePolicies",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListInstanceProfiles",
"iam:PutRolePolicy",
"iam:PassRole",
"iam:GetRole"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"autoscaling:CreateAutoScalingGroup",
"autoscaling:CreateLaunchConfiguration",
"autoscaling:DeleteAutoScalingGroup",
"autoscaling:DeleteLaunchConfiguration",
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeScalingActivities",
"autoscaling:DetachInstances",
"autoscaling:ResumeProcesses",
"autoscaling:SuspendProcesses",
"autoscaling:UpdateAutoScalingGroup"
],
"Resource": [
"*"
]
}
]
}
Related docs:
IAM Roles (AWS)
Google Cloud Credential
In order to launch clusters on GCP via Cloudbreak, you must have a Service Account that Cloudbreak can use to create resources. In addition, you must also have a P12 key associated with that account.
Usually, a user with an "Owner" role can assign roles to new and existing service accounts from IAM & Admin > IAM. If you are using your own account, you should be able to perform this step, but if you are using a corporate account, you will likely have to contact your Google Cloud admin.
The service account must have the following roles enabled:
- Compute Engine > Compute Image User
- Compute Engine > Compute Instance Admin (v1)
- Compute Engine > Compute Network Admin
- Compute Engine > Compute Security Admin
- Storage > Storage Admin
Note that you must include these exact permissions or else you will run into problems.
Related docs:
Service Accounts (Google Cloud)
Service Account for Cloudbreak
General Tips
1. Although the UI option and CLI command for creating a Cloudbreak credential appear to be simple, the related prerequisites are actually complex and, if you are using a corporate cloud account, you may have to contact your cloud account administrator to perform some of the prerequisite steps for you.
2. When meeting the prerequisites for Cloudbreak credential (for example trying to create an IAM role on AWS, trying to create an app registration on Azure, trying to create a Service Account on Google Cloud), an error related to permissions/authorization/roles or an inability to access certain options may mean that you do not have the permissions to perform certain actions and you may have to ask your cloud admin for help.
3. Once the credential has been created and you are trying to create a cluster, an error related to permissions/authorization/roles usually means that the scope of permissions assigned to Cloudbreak (via IAM role on AWS, Contributor role equivalent on Azure, Service Account on Google Cloud) is insufficient. When the scope of permissions is insufficient, you may experience other issues, such as being unable to see provider regions and instance types in the create cluster UI wizard or CLI. As far as I know, Cloudbreak 2.4.0 does not check the permissions provided in the policy assigned to the IAM role (on AWS) or Service Account (Google Cloud). On Azure, on the other hand, these checks are in place.
