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"
}

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

Por defecto, un desencadenador HTTP permite que una función en la nube se ejecute únicamente en respuesta a solicitudes HTTPS. Al permitir las solicitudes HTTP no seguras se exponen los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define un desencadenador HTTP que no aplica puntos finales HTTPS configurando https_trigger_security_level en SECURE_OPTIONAL.

resource "google_cloudfunctions_function" "demo_function" {
...
  trigger_http = true
  https_trigger_security_level = "SECURE_OPTIONAL"
...
}

De manera predeterminada, una instancia de Cloud SQL 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 requiere una instancia de base de datos para aplicar SSL en todas las conexiones configurando require_ssl en false.

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    ip_configuration {
      require_ssl = false
      ...
    }
    ...
  }
}

Por defecto, un servicio Edge Cache 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 define un servicio Edge Cache que no requiere que los clientes usen TLS para la comunicación configurando require_tls en false.

resource "google_network_services_edge_cache_service" "srv_demo" {
...
  require_tls = false
...
}

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión aborda las deficiencias de seguridad halladas en la versión previa. El uso de versiones de los protocolos TLS/SSL inseguras debilita la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform define una política SSL que permite que el equilibrador de carga del proxy permita el uso de conjuntos de cifrado SSL débiles configurando profile en COMPATIBLE.

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "COMPATIBLE"
...
}

Ejemplo 2: El siguiente ejemplo de configuración de Terraform define una política SSL personalizada, que permite específicamente que el equilibrador de carga del proxy permita el uso de un conjunto de cifrado SSL débil denominado TLS_RSA_WITH_AES_128_CBC_SHA.

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "CUSTOM"
  min_tls_version = "TLS_1_2"
  custom_features = ["TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA"]
...
}

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

Una configuración de Terraform crea un depósito de almacenamiento en la nube sin habilitar los registros de uso y almacenamiento. Estos registros contienen datos valiosos para el monitoreo de la red, análisis forense, análisis de seguridad en tiempo real y optimización de gastos.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que crea un depósito de almacenamiento en la nube sin habilitar el uso y el registro de almacenamiento porque falta el argumento log_bucket.

resource "google_storage_bucket" "bucket-demo" {
    name     = "name-demo"
    location = "US"
}

De forma predeterminada, un clúster de Google Kubernetes Engine (GKE) escribe registros en Stackdriver Kubernetes Engine Logging Service. La configuración de Terraform configura un clúster de GKE y deshabilita explícitamente el servicio de registro. Los registros contienen datos valiosos que se utilizan para identificar incidentes de seguridad, supervisar infracciones de directivas y ayudar con los controles de no repudio.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que inhabilita el servicio de registro de un clúster de GKE configurando logging_service en none.

resource "google_container_cluster" "cluster-demo" {
    name            = "name-demo"
    location        = "us-central1-a"
    logging_service = "none"
    ...
}

De manera predeterminada, un clúster de Google Kubernetes Engine (GKE) envía métricas desde pods al servicio de monitoreo de Stackdriver Kubernetes Engine. El script de Terraform configura un clúster de GKE y deshabilita explícitamente el servicio de monitoreo. La ausencia de métricas socava la detección adecuada y la pronta respuesta a los eventos de seguridad.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita el servicio de monitoreo de un clúster de GKE al establecer monitoring_service en none.

resource "google_container_cluster" "cluster-demo" {
    name               = "name-demo"
    location           = "us-central1-a"
    monitoring_service = "none"
    ...
}

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro