Azure
Cyscale enables you to keep track and secure your Azure infrastructure natively. You connect your Azure subscription(s) by registering an AAD service principal which Cyscale uses to read your Azure resources.
Connecting Your Azure Subscription(s)
Once you are ready to connect your Azure subscription(s) and have the required permissions, press the Create button from the top-right corner, select Add Connector, and choose Azure. You will be greeted with a simple multi-step process.
Step 1
In the first step you provide the ID of your Azure Active Directory tenant. You can find your tenant ID using the Azure Portal here.
You have two options for choosing which Azure subscriptions to connect:
-
Connect all subscriptions for the given AAD tenant (default). Resources from all Azure subscriptions which you are authorized to access (you have the Owner role or the classic roles Service Administrator and Co-Administrator) will be imported. You can see a list of the subscriptions in the Azure Portal (check the My role column). Cyscale will automatically use the subscription name to identify the subscription throughout Cyscale (as the connector name). Each subscription will be represented as a separate Cyscale connector.
-
Specify a certain subscription. If you uncheck Onboard all Subscriptions for this Tenant (uncheck for a single Subscription), Cyscale will allow you to specify the ID of a certain Azure subscription (under the given tenant) and give it a name to be used throughout the Cyscale platform.
Step 2
In the second step you create the AAD application, the service principal, and the custom role to grant access for Cyscale to your infrastructure.
Terraform (Default)
Based on the information you provided in the first step, Cyscale generates a ready-to-use Terraform configuration file. You download this file and, using the Terraform CLI either from your machine or using Azure Cloud Shell (click here to directly open the shell), you provision the required Azure resources.
Terraform uses the provider's APIs/SDKs to manage the resource. Cyscale makes use of two Azure providers, hashicorp/azuread for creating the AAD application and service principal, and hashicorp/azurerm for reading the subscriptions and creating/assigning the custom role. You can read more about the available authentication options here and here.
Perhaps the simplest option is to let the provider use the credentials stored by the Azure CLI (az). If you have multiple tenants/subscriptions configured for your CLI, you can switch between them using the command az account set --subscription="SUBSCRIPTION_ID".
Inspect the Terraform configuration file and run terraform init and terraform apply -auto-approve. Terraform creates the resources and outputs the credentials. Since the service principal secret is sensitive information, you have to output the credentials in a file using the command terraform output -json > azure-key.json (the name of the file is not important). Upload this file to Cyscale. You will see something like
Grant admin consent to the created AAD application (Cyscale provides you with the link to the API permissions page of the app) and proceed to the next step. If you do not grant admin consent, Cyscale will not sync AAD users, groups, and applications.
Besides being simple to use, it provides a great way to manage the lifecycle of the created resources (AAD application, service principal, custom role). For example, if you decide to remove the connection to your Azure subscription, you simply run terraform destroy to delete all Cyscale-related resources from your subscription.
Manual
If you prefer setting up the resources manually from the Azure portal, follow the steps described in the application. The manual option is available only when onboarding a specific azure subscription (i.e. uncheck the Onboard all subscriptions checkbox).
While the permissions you grant to Cyscale are limited to reading the configuration of your cloud resources, you might still be concerned about the security of your Azure tenant. Providing the service principal credentials to Cyscale means that any entity with access to these credentials can read your Azure resources.
Cyscale encrypts and stores the credentials in a database accessible only from within the Cyscale infrastructure. Then, a specialized microservice decrypts and uses the credentials to sync your Azure assets. No member of the Cyscale team has access to your credentials.
Step 3
In the third step, Cyscale makes sure the connection to your cloud account can be established and starts the first sync in the background. You can navigate to the cloud account overview page. This page will automatically refresh when Cyscale finishes syncing and assessing your cloud account.
Deep Dive on Permissions
Roles
The permissions Cyscale has with regards to your Azure infrastructure are dictated by the roles you assign to the Cyscale AAD application.
In order to benefit from everything Cyscale has to offer, the following roles are needed:
-
Reader - This is a built-in role which allows read access to all (infrastructure) resources. You can read more about the Reader role in the Azure documentation or on the Access Control (IAM) page of your subscription (see the Azure documentation for the exact steps).
-
Key Vault Reader - Cyscale needs this to check your encryption keys (e.g. rotation policy, expiration, etc.) and link them and the secrets to the resources using them (e.g. encryption with CMK, app service/function app references to Key Vaults). You can see the exact permissions in the Azure documentations. This role does not grant access to the encryption keys/secrets themselves, just to their metadata.
-
Custom Role - Reading certain settings such as security settings for web apps are not covered by the reader role. More precisely, this role allows Cyscale to:
- Get Network Security Groups configured on the network interface of the VM
- View the configured and effective network security group rules applied on a VM
- Get the status of flow logging on a resource
- Get VPN configurations
- Get the configuration of service URI and custom headers for a webhook
- List Web App's security sensitive settings, such as publishing credentials, app settings and connection strings
API Permissions
While roles cover the permissions for cloud infrastructure, API permissions allow Cyscale to read Azure Active Directory resources - i.e. users, groups, apps, etc.
Cyscale requires the following permissions:
Directory.Read.All- enables Cyscale to read the IAM resources (users, groups, applications, etc.) from your tenant.UserAuthenticationMethod.Read.AllandAuditLog.Read.All- enables Cyscale to read MFA and admin information for users.
Since these are considered high privilege permissions, you will have to grant admin consent. You can read more about admin consent in the Azure documentation.
If you do not grant the permissions or the admin consent, Cyscale will not read the corresponding data.
Managing Your Connected Azure Subscription(s)
Once connected, your Azure subscription(s) will show up in the Connectors list. From there, you can either use the inline actions or navigate to the overview page of the cloud account. The available options are:
Configure
You can update the following information for your Azure cloud accounts:
- Name - this helps you better identify the cloud account throughout the Cyscale platform
- Subscription/tenant/application/object ID - you might need to change these in case you configured the connection manually
- Application key - this is the service principal secret. You will have to update this in case you rotate it, or it expires - the configured validity period is 3 years (you can find this in the Terraform configuration file)
Disable/Enable
By default, all connectors are enabled. If you want to prevent Cyscale from syncing and assessing your assets for a certain connector, you can disable it. The state of the connector in Cyscale will be locked until you enable it again. The assets will not be updated based on your actual resources and assessments will not be performed for them.
Sync
You can always trigger a new sync and assessment manually for a given connector (unless the sync is already in progress). This will make Cyscale read all your resources for that particular connector, evaluate the applicable controls, and generate any alerts if necessary.
Service Coverage
The Azure resources that Cyscale can handle are listed in the tables below, along with the number of controls that check their configuration:
| Compute | # of Controls |
|---|---|
| Cluster | 1 |
| Function | 1 |
| FunctionApp | 1 |
| Site | 9 |
| VM | 3 |
| Containers | # of Controls |
|---|---|
| ContainerRegistry | 0 |
| Databases | # of Controls |
|---|---|
| CosmosDBAccount | 1 |
| MariaDBServer | 6 |
| MySQLFlexibleServer | 5 |
| MySQLServer | 6 |
| PostgreSQLFlexibleServer | 6 |
| PostgreSQLServer | 12 |
| RedisInstance | 0 |
| SQLDatabase | 4 |
| SQLServer | 7 |
| StorageAccountTable | 0 |
| IAM | # of Controls |
|---|---|
| IAMApplication | 0 |
| IAMGroup | 0 |
| IAMPermission | 0 |
| IAMRole | 0 |
| IAMServicePrincipal | 0 |
| IAMUser | 1 |
| Integration | # of Controls |
|---|---|
| SBNamespace | 0 |
| SBQueue | 0 |
| StorageAccountQueue | 0 |
| Management | # of Controls |
|---|---|
| CloudAccount | 15 |
| IAMAccountSummary | 0 |
| PolicyAssignment | 0 |
| Pricing | 12 |
| SubscriptionDiagnosticSettings | 1 |
| Networking | # of Controls |
|---|---|
| ApplicationGateway | 0 |
| FlowLog | 1 |
| IPConfiguration | 0 |
| LoadBalancer | 0 |
| NetworkInterface | 0 |
| NetworkWatcher | 1 |
| PublicIP | 0 |
| SecurityGroup | 5 |
| Subnetwork | 0 |
| VirtualNetwork | 0 |
| VPNGateway | 0 |
| Operations | # of Controls |
|---|---|
| ActivityLogAlert | 0 |
| LogProfile | 2 |
| Security | # of Controls |
|---|---|
| AutoProvisioningSetting | 1 |
| KMSKey | 5 |
| KMSSecret | 1 |
| KMSVault | 2 |
| SecurityContact | 3 |
| Storage | # of Controls |
|---|---|
| BlobContainer | 7 |
| Disk | 2 |
| StorageAccount | 7 |
| StorageAccountFileShare | 0 |