Cómo usar Vault para gestionar certificados en APISIX

La puerta de enlace API es un componente básico clave en la gestión del ciclo de vida de las API. Es la entrada de todo el tráfico y es responsable de enrutar las solicitudes de API desde los clientes aguas abajo hacia el servicio aguas arriba correcto para su procesamiento. Por lo tanto, la puerta de enlace API funciona para la comunicación de red entre los servicios aguas arriba y los clientes aguas abajo.

Como una nueva puerta de enlace API nativa de la nube, Apache APISIX proporciona el mecanismo de comunicación TLS/mTLS entre los clientes aguas abajo y APISIX, y entre APISIX y los servicios aguas arriba, para garantizar la seguridad de la red entre ellos. APISIX guarda el certificado SSL como un objeto de certificado SSL y realiza la carga dinámica del certificado SSL a través de la extensión SNI (Server Name Indication) que admite el protocolo TLS.

Para almacenar de manera segura los certificados SSL en APISIX, APISIX ha logrado la integración con HashiCorp Vault, para así realizar la gestión unificada de los certificados SSL aprovechando el almacenamiento seguro de secretos de Vault. Este artículo toma como ejemplo la configuración de la comunicación HTTPS entre el cliente aguas abajo y APISIX para introducir cómo APISIX integra Vault para implementar la gestión de certificados SSL.

¿Qué es un Certificado SSL?

SSL/TLS es un protocolo criptográfico que protege la seguridad de la comunicación de red al establecer una conexión de red cifrada entre las dos partes que se comunican. El protocolo SSL/TLS asegura que los datos se envíen al cliente y servidor correctos mediante la autenticación de usuarios y servidores. Además, el protocolo SSL/TLS puede cifrar los datos de comunicación, garantizando así que los datos no puedan ser robados, alterados o falsificados durante la transmisión.

Un certificado SSL es un certificado digital que autentica la identidad de un sitio web y permite una conexión cifrada utilizando el protocolo SSL/TLS. Un certificado SSL generalmente es emitido por una autoridad de certificación digital (CA) de confianza, que incluye principalmente la siguiente información:

• Nombre de dominio
• Autoridad de certificación
• Firma digital firmada por la autoridad de certificación
• Subdominios asociados
• Fecha de emisión del certificado
• Fecha de expiración del certificado
• La clave pública (mientras que la clave privada es una clave secreta)

¿Qué es HashiCorp Vault?

HashiCorp Vault (en adelante, Vault) es una herramienta de gestión de secretos a nivel empresarial que puede almacenar y gestionar datos sensibles como tokens, contraseñas y certificados. Vault puede integrarse con tecnologías de todo el sistema IT, proporcionar automatización de seguridad basada en identidad y servicios de cifrado, controlar centralmente el acceso a datos y sistemas sensibles, y ayudar a las organizaciones a reducir el riesgo de fugas y exposición de datos, mejorando así la seguridad en la nube y de las aplicaciones.

Cómo Almacenar Certificados SSL de APISIX en Vault

Preparación del Entorno

• Instalar Docker
• Instalar cURL
• Un servicio APISIX en ejecución, o seguir el tutorial de Introducción para implementar un contenedor Docker de APISIX

Implementar y Configurar el Servicio Vault

En esta sección, usaremos Docker para implementar un servicio de contenedor Vault. Puedes omitir esta sección si ya tienes una instancia de servicio Vault disponible en tu entorno.

Crear e implementar un contenedor Vault en modo Dev, llamado apisix-quickstart-vault. Especificar el Token de Vault como apisix-quickstart-vault-token y mapear el puerto 8200 al host:

docker run -d --cap-add=IPC_LOCK \
  -e 'VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200' \
  -e 'VAULT_ADDR=http://0.0.0.0:8200' \
  -e 'VAULT_DEV_ROOT_TOKEN_ID=apisix-quickstart-vault-token' \
  -e 'VAULT_TOKEN=apisix-quickstart-vault-token' \
  --network=apisix-quickstart-net \
  --name apisix-quickstart-vault \
  -p 8200:8200 vault:1.13.0

Seleccionar kv como la ruta de almacenamiento de los certificados SSL de APISIX:

docker exec apisix-quickstart-vault vault secrets enable -path=kv -version=1 kv

Configurar APISIX

APISIX necesita leer los certificados SSL desde Vault, por lo que Vault debe otorgar permiso de lectura a APISIX en la ruta especificada.

Crear una política de Vault llamada apisix-policy.hcl, otorgando a APISIX acceso de lectura a la ruta kv/apisix/:

docker exec apisix-quickstart-vault /bin/sh -c "echo '
path \"kv/apisix/*\" {
    capabilities = [\"read\"]
}
' > /etc/apisix-policy.hcl"

Aplicar el archivo de política creado apisix-policy.hcl a Vault:

docker exec apisix-quickstart-vault vault policy write apisix-policy /etc/apisix-policy.hcl

Crear un objeto secreto de APISIX con el id quickstart-secret-id para guardar la información de conexión de Vault y la ruta de almacenamiento del certificado:

curl -i "http://127.0.0.1:9180/apisix/admin/secrets/vault/quickstart-secret-id" -X PUT -d '
{
    "uri": "http://apisix-quickstart-vault:8200",
    "prefix": "kv/apisix",
    "token" : "apisix-quickstart-vault-token"
}'

Almacenar Certificados SSL en Vault

Crear un certificado CA autofirmado ca.crt y una clave ca.key:

openssl genrsa -out ca.key 2048 && \
  openssl req -new -sha256 -key ca.key -out ca.csr -subj "/CN=ROOTCA" && \
  openssl x509 -req -days 36500 -sha256 -extensions v3_ca -signkey ca.key -in ca.csr -out ca.crt

El certificado SSL server.crt y la clave server.key son emitidos por la CA, y su nombre común (CN) es test.com:

openssl genrsa -out server.key 2048 && \
  openssl req -new -sha256 -key server.key -out server.csr -subj "/CN=test.com" && \
  openssl x509 -req -days 36500 -sha256 -extensions v3_req \
  -CA ca.crt -CAkey ca.key -CAserial ca.srl -CAcreateserial \
  -in server.csr -out server.crt

Copiar el certificado SSL y la clave emitidos al contenedor Vault:

docker cp server.key apisix-quickstart-vault:/root/
docker cp server.crt apisix-quickstart-vault:/root/

Usar el comando vault kv put para almacenar el certificado SSL y la clave como un secreto, la clave es ssl, y la ruta de almacenamiento es kv/apisix:

docker exec apisix-quickstart-vault vault kv put kv/apisix/ssl test.com.crt=@/root/server.crt test.com.key=@/root/server.key

A través del comando anterior, hemos almacenado un secreto llamado ssl en Vault, que contiene 2 pares clave-valor: certificado y clave privada.

Cómo Usar el Certificado SSL de APISIX Almacenado en Vault

APISIX admite el cifrado de red TLS/mTLS entre los clientes aguas abajo y APISIX, y entre APISIX y los servicios aguas arriba, donde se pueden usar los certificados SSL almacenados en Vault. Tomaremos como ejemplo la configuración de la comunicación HTTPS entre el cliente y APISIX para demostrar cómo usar el certificado SSL almacenado en Vault en APISIX.

Configurar la Comunicación HTTPS Entre el Cliente y APISIX

Crear un objeto de certificado SSL para guardar el certificado SSL:

curl -i "http://127.0.0.1:9180/apisix/admin/ssls" -X PUT -d '
{
  "id": "quickstart-tls-client-ssl",
  "sni": "test.com",
  "cert": "$secret://vault/quickstart-secret-id/ssl/test.com.crt",
  "key": "$secret://vault/quickstart-secret-id/ssl/test.com.key"
}'

El sni de este objeto es test.com, que coincide con el CN que emitió el certificado. El cert y key corresponden al certificado y clave privada emitidos, que se obtienen automáticamente desde Vault a través del localizador de recursos secretos establecido, y las reglas del localizador de recursos son:

$secret://$manager/$id/$secret_name/$key

• manager: servicio de gestión de claves Vault
• id: ID del recurso secreto de APISIX
• secret_name: el nombre del secreto en Vault
• key: la clave del par clave-valor en el secreto llamado secret_name

Verificar la Comunicación HTTPS Entre el Cliente y APISIX

Crear una ruta para reenviar todas las solicitudes enviadas a /ip al upstream httpbin.org:

curl -i "http://127.0.0.1:9180/apisix/admin/routes" -X PUT -d '
{
  "id": "quickstart-client-ip",
  "uri": "/ip",
  "upstream": {
    "nodes": {
      "httpbin.org:80":1
    },
    "type": "roundrobin"
  }
}'

Usar cURL para enviar una solicitud a https://test.com:9443/ip, test.com resuelve a 127.0.0.1:

curl -ikv --resolve "test.com:9443:127.0.0.1" "https://test.com:9443/ip"

Si la configuración es exitosa, el proceso de handshake TLS entre el cliente y APISIX devuelto por cURL será el mismo que los siguientes resultados:

* Added test.com:9443:127.0.0.1 to DNS cache
* Hostname test.com was found in DNS cache
*   Trying 127.0.0.1:9443...
* Connected to test.com (127.0.0.1) port 9443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=test.com
*  start date: Apr 21 07:47:54 2023 GMT
*  expire date: Mar 28 07:47:54 2123 GMT
*  issuer: CN=ROOTCA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x556274d632e0)
> GET /ip HTTP/2
> Host: test.com:9443
> user-agent: curl/7.74.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
HTTP/2 200
...

Resumen

Hemos introducido cómo APISIX integra Vault para implementar la gestión de certificados SSL, y mostramos los pasos de configuración e integración en detalle tomando como ejemplo la comunicación HTTPS entre los clientes aguas abajo y APISIX.

Para conceptos relacionados y escenarios de uso de los certificados SSL en APISIX, consulta los siguientes artículos:

• Certificados SSL
• Configurar HTTPS Aguas Arriba
• Configurar HTTPS Entre el Cliente y APISIX
• Configurar mTLS Entre el Cliente y APISIX