If a Compute Engine instance is created without a user-managed service account specification, Google Cloud assigns a default service account to the instance. The access rights of the default service account are often beyond what the instance needs to operate. This violates the least privilege principle.

Example 1: The following example shows a Terraform configuration that creates a Compute Engine instance without a user-managed service account specification. The service_account block is missing.

resource "google_compute_instance" "instance-demo" {
    name = "name-demo"
    machine_type = "e2-micro"
    boot_disk {
    ...
    }
    network_interface {
    ...
    }
}

The GKE control plane makes global decisions about a cluster and by default, many of its API endpoints are publicly accessible. Adding authorized networks using an allow list can provide network level protection for control plane access.

Example 1: The following example Terraform configuration sets up a public cluster without defining any authorized networks in the master_authorized_networks_config block. As a result, the GKE control plane API endpoints are publicly accessible.

resource "google_container_cluster" "cluster_demo" {
  name = "name-demo"
}

Failure to block unwanted network traffic expands a cloud service's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

Private GKE nodes do not have external IP addresses. Pods that run on these nodes cannot communicate beyond the cluster perimeter. Disabling a public endpoint protects the GKE cluster by limiting its management to internal private IP addresses. Failure to enforce a private endpoint and private nodes exposes the cluster to the public.

Example 1: The following Terraform configuration permits any public IP address to access cluster nodes and the control plane because enable_private_nodes and enable_private_endpoint are set to false.

resource "google_container_cluster" "cluster-demo" {
...
  private_cluster_config {
    enable_private_endpoint = false
    enable_private_nodes = false
  }
...
}

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

Sensitive Azure ARM template parameters, such as passwords, typically use the @secure() decorator.

For parameters that use the @secure() decorator, 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 discoverable 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.

@secure()
param rootPassword string = 'HardcodedPassword'

param adminLogin string
param sqlServerName string
...

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.