By default, Azure storage accounts created by Ansible accept connections from clients on any network.

Loose access configurations unnecessarily expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

Example 1: The following example Ansible task fails to restrict network access to an Azure storage account.

- name: storage with network acl
azure_rm_storageaccount:
  resource_group: testGroup
  name: sa001
  type: Standard_RAGRS
  network_acls:
    bypass: AzureServices,Metrics
    default_action: Deny
    ip_rules:
      - value: 0.0.0.0/0
        action: Allow

By default, Ansible tasks do not enable Azure MySQL Database transport encryption (as per Azure.Azcollection v1.11.0 and earlier).

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example Ansible task defines an Azure MySQL Database with transport encryption disabled.

- name: Create MySQL Server
azure.azcollection.azure_rm_mysqlserver:
    resource_group: testGroup
    name: testMySQL
    sku:
    name: B_Gen5_1
    tier: Basic
    location: westeurope
    storage_mb: 8096
    version: 5.6
    enforce_ssl: false
    admin_username: test
    admin_password: complicatedPass

By default, Ansible tasks do not enable Azure Database for PostgreSQL transport encryption (as per Azure.Azcollection v1.11.0 and earlier).

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example Ansible task defines an Azure Database for PostgreSQL with transport encryption disabled.

- name: Create Postgres Server
  azure.azcollection.azure_rm_postgresqlserver:
    resource_group: testGroup
    name: testPostgres
    sku:
      name: B_Gen5_1
      tier: Basic
    location: westeurope
    storage_mb: 8096
    version: 5.6
    enforce_ssl: false
    admin_username: test
    admin_password: complicatedPass

Unencrypted communication channels are prone to eavesdropping and tampering.

By default, the https_only setting is set to yes enforcing secure transfer for an Azure storage account. However, this setting can be explicitly disabled.

Disabling secure transfer exposes the stored data to unauthorized access, potential theft, and tampering.

Example 1: The following Ansible task shows a storage account that does not enforce secure transfer.

- name: create a storage account
  azure_rm_storageaccount:
    resource_group: testResGroup
    name: sa0001
    type: Standard_GRS
    https_only: no

By default, Azure Kubernetes Service (AKS) clusters created by Ansible do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example Ansible task shows an AKS cluster that does not send log events to Azure Monitor.

- name: AKS Instance
  azure_rm_aks:
    name:
    resource_group: testResourceGroup
    location: eastus
    ...
    addon:
      monitoring:
        log_analytics_workspace_resource_id: logws001
        enabled: no

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

Sensitive Azure ARM template parameters, such as passwords, typically use the securestring or secureobject types.

For parameters that use a secure type, the parameter values are not logged or stored in the deployment history.

However, if a hardcoded default value is configured for a secure type, that default value is readable to anyone who can access the template or the deployment history.

Hard-coded secrets can compromise security in a way that is not easy to remedy. After the software is in production, an update is required to change the compromised secret.

In the case of a secret that is used to encrypt data, key-rotation steps must be administered to decrypt and re-encrypt all the data protected by the compromised key.

Example 1: The following template shows a parameter with a secret type that has a hardcoded default value.

{
    ...
    "parameters": {
        "rootPassword": {
            "defaultValue": "HardcodedPassword",
            "type": "secureString"
        },
        "adminLogin": {
            "type": "string"
        },
        "sqlServerName": {
            "type": "string"
        }
    },
    ...
}