Para automatizar la rotación de autoridades raíz en su entorno Kafka, Zendesk hizo un uso específico de rutas de certificación.
¿Busca un uso inusual de las rutas de certificación? Pregúntale a Zendesk.
El uso en cuestión consistió en incluir en dichas rutas varias autoridades raíz de certificación mTLS. El contexto: un proyecto destinado a automatizar la rotación de estos últimos en un entorno Kafka.
mTLS se ha implementado en este entorno durante aproximadamente tres años. Zendesk utiliza una herramienta interna llamada Temp Auth para la autenticación en los almacenes de datos . Esto incluye un contenedor de inicio que proporciona autenticadores para pods basados en recursos personalizados asociados con proyectos. Varios operadores de Kubernetes aprovisionan almacenes de datos , configuran el acceso y completan autenticadores en el administrador de secretos de Vault.
El contenedor init recupera los autenticadores en el administrador según los almacenes de datos declarados por el proyecto y luego los comunica a los contenedores de la aplicación. También gestiona, cuando se acerca la caducidad de los autenticadores, su renovación o el desalojo de pods .
En la configuración de Zendesk, los certificados de cliente y corredor provienen de la misma autoridad interna, creada a través del motor Vault PKI. Dados los retrasos en la propagación, no podríamos imaginar una rotación instantánea. Por lo tanto, el enfoque aplicado implica un cambio gradual, basado en una autoridad principal (emisora de certificados) y otras secundarias.
Uso ad hoc de rutas de certificación
La gestión del proceso de rotación requiere un estado compartido: todos los sistemas deben conocer la autoridad primaria y, si corresponde, saber en qué autoridad secundaria confiar. Para esto, Zendesk utiliza una entrada de valor-clave de Consul (kafka-pki/root). Contiene las rutas de Vault de las autoridades primarias y secundarias.
Sobre esta base, podemos construir un “almacén de claves” y un “almacén de confianza” de Kafka. El primero contiene el certificado del cliente (y la clave privada). El segundo contiene todos los emisores (primarios y secundarios)… y permite así comunicarse con cualquier broker , independientemente de si su certificado proviene de una u otra autoridad.
Desde la versión 1.11, lanzada a mediados de 2022, Vault permite asociar varias autoridades al mismo motor PKI. Una API le permite definir el transmisor predeterminado. A partir de ahí, ¿cómo dar a conocer lo segundo? Los clientes pueden consultar dicha API para recuperar una lista, excepto que Temp Auth no comprende la lógica de múltiples emisores.
Ante este obstáculo, Zendesk recurrió a las rutas de certificación que emite Vault. Inicialmente se habló de operar una autoridad de certificación intermedia que a su vez tendría dos autoridades matrices. De esta manera, no importa en qué autoridad principal se confíe, también se confía en la autoridad intermedia.
Finalmente, abandonamos el principio de la cadena… para integrar las dos autoridades raíz directamente en la ruta de certificación, utilizada como Truststore. Esto funciona porque los clientes y los corredores dependen del mismo emisor. Temp Auth no percibe lo que está sucediendo: simplemente genera certificados TLS estándar.
Un proceso inicialmente semiautomático
En la implementación mTLS original, la rotación de autoridades raíz era semiautomática (un ingeniero intervino en Terraform). Una elección asumida debido a la relativa rareza del proceso. Sin embargo , los errores en el proveedor Terraform para Vault impulsaron la automatización. Se ejecuta una tarea periódicamente para:
– Enumere todas las autoridades emisoras en /kafka-pki colocando las más antiguas primero, luego conserve las tres primeras
– Si hay menos de tres, crea uno y repite el proceso desde el paso 1.
– Asignar las tres autoridades a las variables anterior, actual y siguiente.
– Si el siguiente es anterior a la variable ROTATION_TIME, cree un nuevo elemento y reorganice los demás (el nuevo elemento pasa a ser el siguiente, el antiguo siguiente pasa a ser el actual, etc.)
– Establecer la ruta de certificación de los tres emisores en [anterior, actual, siguiente]
– En Vault, designe corriente como emisor principal (si aún no es el caso)
– Eliminar transmisores que no están en [anterior, actual, siguiente]
En caso de falla, sin importar el paso, el proceso puede reanudarse, enfatiza Zendesk. Y en ningún momento deja a Vault en un estado no deseado.
Para completar la migración, Zendesk introdujo el nuevo endpoint multiemisor como second_issuer en su sistema Consul. Modificó el contenedor de inicio para que confíe en todas las entradas de la ruta de certificación. De este modo, los propios clientes confiarían en todas las autoridades emisoras (la antigua y las tres nuevas). Una vez que el punto final se promueve a Emisor_primario y se completa la propagación, todos los clientes confían en las mismas autoridades raíz, independientemente del contenedor de inicio utilizado.Fuente: NetMedia-Francia(CB), traducido al español.
Ilustración principal © Настя Шевчук – Adobe Stock
Contacto