Si se crea una instancia de Compute Engine sin una especificación de cuenta de servicio administrada por el usuario, Google Cloud asigna una cuenta de servicio predeterminada a la instancia. Los derechos de acceso de la cuenta de servicio predeterminada a menudo van más allá de lo que la instancia necesita para operar. Esto viola el principio de privilegio mínimo.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que crea una instancia de Compute Engine sin una especificación de cuenta de servicio administrada por el usuario. Falta el bloque service_account.

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

Si no se bloquea el tráfico de red no deseado, se amplía la superficie de ataque de un servicio en la nube.

De manera predeterminada, el reenvío de IP está deshabilitado en una instancia de Compute Engine. El reenvío de IP permite enviar y recibir paquetes con direcciones IP de origen o destino que no coinciden. Un atacante puede explotar esto enrutando paquetes a través de la instancia de Compute Engine para eludir el control de acceso a la red.

Ejemplo 1: La siguiente configuración de Terraform habilita el reenvío de IP configurando can_ip_forward como true.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  can_ip_forward = true
  ...
}

Por defecto, una instancia de Compute Engine no es una máquina virtual confidencial. Una máquina virtual confidencial utiliza criptografía basada en hardware para la protección de datos en uso y para admitir certificaciones remotas. Las claves de instancia por máquina virtual dedicadas no exportables mantienen la memoria de la máquina virtual encriptada, y protegen así la confidencialidad e integridad de la máquina virtual contra el acceso del proveedor de la nube a través del hipervisor con privilegios más altos.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita la máquina virtual confidencial configurando enable_confidential_compute en false.

resource "google_compute_instance" "default" {
  ...
  confidential_instance_config {
    enable_confidential_compute = false
  }
  ...
}

De forma predeterminada, Google Cloud Compute Engine cifra todos los datos en reposo. Una clave de cifrado proporcionada por el cliente (CSEK), si se especifica, cifra las claves de cifrado de datos. Google no almacena ninguna CSEK en una instancia de Compute Engine y no puede acceder a los datos protegidos a menos que se proporcione la CSEK correcta.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define un disco persistente para una instancia de Compute Engine. Falta el bloque disk_encryption_key, por lo que no hay CSEK para proteger las claves de cifrado de datos.

resource "google_compute_disk" "compute-disk-demo" {
    name  = "test-disk"
    type  = "pd-ssd"
}

De manera predeterminada, puede usar las claves SSH almacenadas en los metadatos del proyecto para acceder a todas las instancias de Compute Engine en un proyecto. Esto amplía en gran medida la superficie de ataque accesible a cualquier clave SSH comprometida y viola el principio de privilegio mínimo.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que permite inicios de sesión SSH en todo el proyecto configurando block-project-ssh-keys en false en el argumento metadata.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    block-project-ssh-keys = false
    ...
  }
  ...
}

Si no se bloquea el tráfico de red no deseado, se amplía la superficie de ataque de un servicio en la nube. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

De forma predeterminada, el puerto serie de una instancia de Compute Engine está deshabilitado para el acceso a la consola. Habilitar el acceso a la consola en serie puede permitir que los atacantes se conecten a la instancia de Compute Engine desde cualquier dirección IP porque el puerto en serie no admite restricciones de acceso basadas en IP.

Ejemplo 1: La siguiente configuración de Terraform permite el acceso a la consola en serie interactiva configurando serial-port-enable como true en el argumento metadata.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    serial-port-enable = true
    ...
  }
  ...
}

Cada característica de seguridad del servicio en la nube tiene una capacidad única para prevenir o mitigar una amenaza conocida. Cualquier característica deshabilitada por intención o error no ofrece protección.

Deshabilitar cualquier opción de Shield VM permite a un atacante eludir las restricciones de seguridad implementadas para un sistema operativo invitado en una instancia de Compute Engine. Las opciones de Shield VM recomendadas (y sus correspondientes identificadores de configuración de Terraform) son las siguientes:

- Monitoreo de integridad (enable_integrity_monitoring)
- Arranque seguro (enable_secure_boot)
- Módulo de plataforma virtual de confianza (enable_vtpm)

Ejemplo 1: La siguiente configuración de Terraform establece enable_integrity_monitoring como false en el bloque shielded_instance_config. No todas las opciones de Shield VM recomendadas están habilitadas.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  shielded_instance_config {
    enable_integrity_monitoring = false
    enable_secure_boot = true
    enable_vtpm = true
  }
  ...
}

Por defecto, los servicios Edge Cache aceptan conexiones no cifradas y no seguras. Esto expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define un servicio Edge Cache que permite a los clientes usar HTTP para la comunicación configurando https_redirect en false.

resource "google_network_services_edge_cache_service" "srv_demo" {
...
  routing {
...
    path_matcher {
...
      route_rule {
...
        url_redirect {
          https_redirect = false
        }
      }
    }
  }
}

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

El plano de control de GKE toma decisiones globales sobre un clúster y, de forma predeterminada, muchos de sus puntos finales de API son de acceso público. Agregar redes autorizadas mediante una lista de permitidos puede brindar protección a la red para el acceso al plano de control.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform establece un clúster público sin definir ninguna red autorizada en el bloque master_authorized_networks_config. Como resultado, los puntos finales de la API del plano de control de GKE son de acceso público.

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

De forma predeterminada, la autenticación basada en certificados está deshabilitada en los nuevos clústeres que ejecutan GKE en la versión 1.12 y posteriores. Con la autenticación basada en certificados, un usuario presenta un certificado que el servidor API de Kubernetes verifica con la autoridad de certificación especificada. Sin embargo, no hay forma de revocar el certificado cuando el usuario abandona o pierde las credenciales. Esto hace que la autenticación basada en certificados no sea adecuada para los usuarios finales.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform habilita la autenticación basada en certificados de clientes de GKE configurando issue_client_certificate en true en el bloque master_auth.

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    client_certificate_config {
      issue_client_certificate = true
      ...
    }
    ...
  }
...
}

Un servidor API de Kubernetes, la entidad de administración central de un clúster, acepta la autenticación HTTP básica para autenticar a los usuarios. La autenticación HTTP básica está en desuso y es susceptible a ataques por fuerza bruta y expone las credenciales de usuario a los atacantes en un entorno mal configurado.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que habilita la autenticación básica HTTP en un clúster de GKE al establecer el username y la password en valores no vacíos en el bloque master_auth.

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    username = "foo"
    password = "bar"
  }
...
}

De forma predeterminada, el control de acceso basado en atributos (ABAC) está deshabilitado en los nuevos clústeres que ejecutan GKE en la versión 1.8 y posteriores. ABAC puede otorgar estáticamente, a un usuario específico o a un grupo, acceso a un recurso, además de los proporcionados por el Control de acceso basado en roles (RBAC) o la Gestión de acceso e identidad (IAM). Esto complica la administración de autorizaciones y socava el control de acceso centralizado.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que habilita la autorización ABAC heredada en un clúster de GKE configurando enable_legacy_abac en true.

resource "google_container_cluster" "container_cluster_demo" {
...
  enable_legacy_abac = true
...
}

Cada característica de seguridad del servicio en la nube está diseñada para prevenir o mitigar una amenaza conocida. Cuando se desactiva por intención o negligencia, no ofrece protección.

Por defecto, si un nodo de GKE informa repetidamente un estado incorrecto durante un período determinado, GKE inicia un proceso de reparación para ese nodo. La desactivación de la reparación automática de nodos evita los reemplazos oportunos y automatizados de nodos en mal estado en los que se pueden ejecutar cargas de trabajo de misión crítica.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform inhabilita las actualizaciones automáticas de los nodos de Kubernetes configurando auto_repair como false en el bloque management.

resource "google_container_node_pool" "node-pool-demo" {
...
  management {
    auto_repair = false
    ...
  }
...
}

Si no se bloquea el tráfico de red no deseado, se amplía la superficie de ataque de un servicio en la nube. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Los nodos privados de GKE no tienen direcciones IP externas. Los pods que se ejecutan en estos nodos no pueden comunicarse más allá del perímetro del clúster. Deshabilitar un extremo público protege el clúster de GKE al limitar su administración a las direcciones IP privadas internas. Si no se aplica un punto final privado y nodos privados, el clúster se expone al público.

Ejemplo 1: La siguiente configuración de Terraform permite que cualquier dirección IP pública acceda a los nodos del clúster y al plano de control porque enable_private_nodes y enable_private_endpoint se establecen como false.

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

De manera predeterminada, los nodos de GKE se ejecutan con Container-Optimized OS (COS). COS es una imagen del sistema operativo que está optimizada para ejecutar nodos GKE en instancias de Google Compute Engine. La exclusión voluntaria del valor predeterminado renuncia a los beneficios de una mayor seguridad y eficiencia.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform configura un grupo de nodos de GKE que no ejecutan COS porque image_type está configurado como una imagen que no es COS en el bloque node_config.

resource "google_container_node_pool" "node_pool_demo" {
  ...
  node_config {
    image_type = "UBUNTU"
    ...
  }
  ...
}

De forma predeterminada, GKE actualiza automáticamente los nodos de Kubernetes a versiones estables más recientes. Las actualizaciones automáticas, que garantizan la aplicación oportuna de parches a las vulnerabilidades de software conocidas, están deshabilitadas.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform inhabilita las actualizaciones automáticas de los nodos de Kubernetes configurando auto_upgrade en false en el bloque management.

resource "google_container_node_pool" "node_pool_demo" {
...
  management {
    auto_upgrade = false
    ...
  }
...
}

De forma predeterminada, un nuevo proyecto de Google Cloud comienza con una red de todo el proyecto. La red predeterminada se completa previamente con reglas de firewall, que permiten la comunicación sin restricciones entre las instancias de Compute Engine en el mismo proyecto y exponen al público los puertos sensibles a la seguridad de todas las instancias. Los puertos afectados incluyen TCP 22 (SSH) y TCP 3389 (RDP). Cualquier instancia insuficientemente protegida es susceptible de sufrir accesos no autorizado.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform permite la creación automática de una red para todo el proyecto configurando auto_create_network en true.

resource "google_project" "project-demo" {
...
  auto_create_network = true
...
}

La configuración de Terraform establece el alcance de acceso de una cuenta de servicio en cloud-platform, lo que permite el acceso a la mayoría de las API de Google Cloud. Esto amplía, en gran medida, la superficie de ataque accesible para cualquier instancia de Compute Engine comprometida y viola el principio de privilegio mínimo.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que establece el ámbito de acceso (scopes) de la cuenta de servicio en cloud-platform.

resource "google_compute_instance" "compute-instance-demo" {
    name         = "name-demo"
    machine_type = "e2-micro"
    ...
    service_account {
        email  = "foobar.service.account@example.com"
        scopes = ["cloud-platform"]
    }
}

Por defecto, el dominio de una aplicación de App Engine acepta conexiones no cifradas y no seguras. Esto expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que no contiene un bloque ssl_settings para el dominio denominado example.com. Como resultado, el dominio personalizado de la aplicación App Engine no es compatible con HTTPS.

resource "google_app_engine_domain_mapping" "domain_mapping" {
  domain_name = "example.com"
}