Comunicaciones seguras, autenticación mutua y autorizaciones con intenciones entre servicios usando Consul Connect y Nomad

El método habitual para proporcionar seguridad a varios sistemas que se comunican por red ha sido utilizar protocolos de comunicaciones cifrados, poner cortafuegos e impedir una comunicación directa con algunos sistemas como las base de datos en ocasiones en base a direcciones IP. La configuración estática cuando hay que adaptarla por añadir nuevos sistemas es difícil de cambiarla.

En un entorno en la nube, aún con sus propias medidas de seguridad y aislamiento que implementan, la infraestructura no es confiable por ser compartida con otras organizaciones como demuestran los fallos de seguridad de meltdown y spectre de los procesadores por su ejecución especulativa. En una arquitectura dinámica de múltiples microservicios e instancias una configuración estática no es práctica para un sistema que por naturaleza es altamente dinámico y en un medio de computación compartido no confiable hay que adoptar medidas adicionales.

La propuesta que ofrecen algunas herramientas nativas para la computación en la nube es proporcionar seguridad realizando cada comunicación servicio a servicio de forma cifrada y transparente para las aplicaciones incluso si estas no implementan comunicación cifrada de forma nativa, con autenticación mutua entre los dos servicios utilizando su identidad en vez de direcciones IP y con autorizaciones basadas en intenciones fáciles de administrar y cambiar.

Una de estas herramientas es Consul que proporciona la funcionalidad de registro y descubrimiento de servicios y conectividad entre esos servicios. Consul Connect proporciona comunicaciones seguras de forma transparente para las aplicaciones.

El esquema de funcionamiento de Consul Connect es hacer que los servicios no se comuniquen directamente entre ellos sino que utilizan proxys, la creación del enlace de comunicación se delega en Consul que crea los proxys y con ellos le es posible proporcionar comunicaciones seguras, con autenticación mutua y posibilitando autorización con intenciones. Las intenciones son los permisos que establece el operador de Consul para establecer que dos servicios tiene permitido la comunicación entre ellos, cualquier intento de comunicación si no está aprobado de forma explícita por su intención no se permite.

Otra de las herramientas de HashiCorp es Nomad que proporciona la funcionalidad de orquestador de servicios, creando las instancias de los servicios necesarias en los diferentes nodos de computación. Nomad se integra con Consul y Consul Connect haciendo más sencillo utilizar todas estas tecnologías.

En el siguiente ejemplo sigo la guía de ejemplo para probar Consul Connect con Nomad utilizando Envoy para crear los proxys. Para ejecutar el ejemplo es necesario obtener los binarios de Consul, Nomad y Envoy además de las utilidades de comunicaciones de cni-plugins y Docker.

Hay que instalar los paquetes de Consul, Nomad, Envoy y cni-plugins de la distribución GNU/Linux o la descarga directa de sus binarios accesibles en la variable PATH del sistema utilizada por los intérpretes de comandos para buscar comandos. Para obtener Envoy hay que ejecutar el siguiente comando que instala el binario de Envoy en la carpeta /usr/local/bin que incluida en la variable PATH.

1
2

$ curl -L https://getenvoy.io/cli | bash -s -- -b /usr/local/bin
$ getenvoy run standard:1.11.2 -- --version

Nomad requiere que los cni-plugins esté ubicados en la carpeta /opt/cni/bin, en Arch Linux se instalan en la carpeta /usr/lib/cni/ por lo que hay que crear un enlace simbólico para que sean encontrados por Nomad. En Ubuntu la opción es realizar la instalación descargando el paquete manualmente.

1
2
3

$ curl -L -o cni-plugins.tgz https://github.com/containernetworking/plugins/releases/download/v0.8.6/cni-plugins-linux-amd64-v0.8.6.tgz
$ sudo mkdir -p /opt/cni/bin
$ sudo tar -C /opt/cni/bin -xzf cni-plugins.tgz

1
2

$ sudo pacman -s cni-plugins
$ sudo ln -s /usr/lib/cni/ /opt/cni/bin

Con los binarios necesarios instalados hay que iniciar Consul y Nomad con los siguientes comandos que los arrancan en su configuración de desarrollo y con el soporte para Consul Connect en Nomad.

1
2

$ consul agent -dev
$ sudo nomad agent -dev-connect

El siguiente paso es enviar el Nomad la definición de los servicios para que planifique su ejecución, en este caso utilizando contenedores de Docker que ha de estar instalado previamente y con su servicio del sistema iniciado.

• Introducción y características de Docker

La definición incluye dos servicios uno que proporciona un contador y otro que obtiene el valor de ese contador y lo muestra en una página web. En la definición del servicio count-api se define que va a ofrecer su comunicación por red en el puerto 9001 asociado a la interfaz de red localhost de modo que este puerto solo pueda ser accedido por Consul a través del proxy que crea, la definición del servicio count-dashboard ofrece su servicio en el puerto 9002 y que tiene tiene como dependencia el servicio count-api para el que Consul crea un nuevo proxy, el servicio count-dashboard se conecta al puerto 8080 para comunicarse con el servicio count-api mediante los proxys de Consul Connect. Los servicios solo se comunican con los proxys y son los proxys los que se comunican entre ellos.

1
2

$ nomad run connect.nomad

En la definición de job las partes relativas a Consul Connect están en los bloques o stanzas connect, en el caso de count-api simplemente para indicar que desea un proxy y en el caso de count-dashboard para indicar que desea un proxy para conectarse al servicio count-api, la variable de entorno COUNTING_SERVICE_URL contiene la dirección del proxy que permite la conexión con count-api.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

job "countdash" {
  datacenters = ["dc1"]

  group "api" {
    network {
      mode = "bridge"
    }

    service {
      name = "count-api"
      port = "9001"

      connect {
        sidecar_service {}
      }
    }

    task "web" {
      driver = "docker"

      config {
        image = "hashicorpnomad/counter-api:v1"
      }
    }
  }

  group "dashboard" {
    network {
      mode = "bridge"

      port "http" {
        static = 9002
        to     = 9002
      }
    }

    service {
      name = "count-dashboard"
      port = "9002"

      connect {
        sidecar_service {
          proxy {
            upstreams {
              destination_name = "count-api"
              local_bind_port  = 8080
            }
          }
        }
      }
    }

    task "dashboard" {
      driver = "docker"

      env {
        COUNTING_SERVICE_URL = "http://${NOMAD_UPSTREAM_ADDR_count_api}"
      }

      config {
        image = "hashicorpnomad/counter-dashboard:v1"
      }
    }
  }
}

El resultado es esta aplicación sencilla de ejemplo que muestra un contador en una página web con el tiempo se va incrementando. En las consolas de administración de Consul se observan los servicios registrados y en Nomad la ejecución de los mismos.

Dado que el servicio count-dashboard se conecta con el servicio count-api a través de los proxys que crea Consul, Consul es capaz de permitir o denegar la comunicación con las intenciones. Las intenciones son las autorizaciones concedidas a cada servicio origen y servicio destino de comunicación. La ventaja de las intenciones es que son agnósticas de la red como redes físicas, en la nube, basadas en software o cualesquiera otras ya que están basadas en la identidades de los servicios.

En el modo desarrollo de Consul aún sin una intención la comunicación se autorizan las comunicaciones pero si se crea una intención que deniegue la comunicación desde el servicio count-dashboard a count-api el servicio count-dashboard no es capaz de recuperar el contador y se muestra desconectado. Cambiando la intención para que autorice el tráfico la comunicación se restaura y el servicio count-dashboard vuelve a mostrar el contador.