PKIaaS para plataformas de desarrollo internas

Los equipos de ingeniería de plataformas reciben solicitudes repetidas de lo mismo, presentadas de diferentes maneras. Los desarrolladores necesitan certificados TLS para sus servicios. Las canalizaciones de CI/CD requieren credenciales que no sean claves API codificadas. Las cargas de trabajo de Kubernetes necesitan identidades mTLS. El equipo de seguridad exige que todo esto se implemente con una política coherente, una emisión auditable y sin la intervención manual del equipo de PKI en cada solicitud. La respuesta que suele dar el equipo de plataforma es una cuenta de servicio, un certificado compartido o un script de certificado autofirmado incluido en el repositorio. Ninguna de estas opciones es la solución adecuada.

La solución ideal es PKIaaS como funcionalidad de plataforma: el equipo de plataforma integra una autoridad de certificación gobernada en el IDP una sola vez, la expone a través de ACME, cert-manager y una API, y los desarrolladores obtienen emisión de certificados de autoservicio que aplica automáticamente las políticas del equipo de seguridad sin necesidad de que el desarrollador conozca qué es un perfil de certificado. Esta publicación explica cómo implementar esta funcionalidad.

Respuesta rápida: ¿Cómo se ve PKIaaS como una capacidad de IDP?

PKIaaS se convierte en una capacidad de IDP cuando el equipo de la plataforma configura el backend de CA de PKIaaS, define perfiles de certificado para cada tipo de carga de trabajo y expone esos perfiles a través de las interfaces estándar de la plataforma: un ClusterIssuer de cert-manager para cargas de trabajo de Kubernetes, un punto final ACME con autenticación OIDC para trabajos de canalización de CI/CD, un módulo de proveedor de Terraform para consumidores de infraestructura como código y una plantilla de catálogo de servicios de Backstage para equipos que prefieren un flujo de solicitud basado en interfaz de usuario. Los desarrolladores solicitan certificados a través de la interfaz que ya utilizan. La CA de PKIaaS aplica la política de certificados del equipo de la plataforma sin ninguna complejidad para el desarrollador. La capa CLM proporciona al equipo de seguridad visibilidad de auditoría de todo el conjunto de certificados en todos los inquilinos de la plataforma.

Puntos Clave

• Los equipos de plataforma son los responsables de la política de emisión de certificados, no los desarrolladores de aplicaciones. El equipo de plataforma establece las directrices una sola vez (perfiles de certificados válidos, restricciones de nomenclatura, límites de período de validez, mínimos de algoritmos de clave). Los desarrolladores solicitan certificados dentro de esas directrices sin saber que existen. Este es el mismo modelo que los equipos de plataforma aplican a las imágenes base de contenedores, los módulos de Terraform y las configuraciones de observabilidad.
• cert-manager es la interfaz de Kubernetes entre las cargas de trabajo de los desarrolladores y la CA de PKIaaS. El equipo de la plataforma implementa cert-manager y configura un ClusterIssuer que apunta al punto final ACME de PKIaaS. Los desarrolladores declaran los recursos de certificado en sus manifiestos de Kubernetes; cert-manager se encarga de la emisión, el almacenamiento como secretos de Kubernetes y la renovación automática. No se requiere ninguna interacción por parte del desarrollador después de la declaración inicial.
• El intercambio de tokens OIDC permite obtener certificados para canalizaciones de CI/CD sin necesidad de compartir secretos previamente. Las plataformas modernas de CI/CD (GitHub Actions, GitLab CI, CircleCI) emiten tokens OIDC para los trabajos de la canalización, los cuales se pueden canjear por certificados PKIaaS de corta duración mediante el mecanismo ACME External Account Binding. El certificado del trabajo de la canalización solo es válido durante la duración del trabajo y caduca automáticamente. No se requiere rotación de secretos.
• Las plantillas de solicitud de certificados eliminan la necesidad de conocimientos especializados para las solicitudes de certificados por parte de los desarrolladores. Estas plantillas definen los patrones de nomenclatura de sujeto válidos, los tipos SAN, los períodos de validez y el uso de claves para cada categoría de certificado. Los desarrolladores seleccionan una plantilla y la plataforma aplica sus restricciones. Los desarrolladores no necesitan saber qué es un OID de uso de clave extendido ni qué establecen los requisitos básicos del Foro CA/B sobre el formato SAN.
• El calendario de validez máxima de 47 días del CA/B Forum SC-081v3 (vigente a partir del 15 de marzo de 2029) hace obligatoria la renovación automática para todos los certificados TLS públicos. Los equipos de plataforma que integran la renovación automática con respaldo PKIaaS en el IDP ahora están desarrollando la solución de cumplimiento antes de la fecha límite, en lugar de apresurarse a implementar la automatización en un conjunto de certificados administrados manualmente.

El problema de la ingeniería de plataformas con los certificados

Los equipos de plataforma se enfrentan a una versión específica del problema de la gestión de certificados que difiere del problema de gestión de certificados a nivel empresarial al que se enfrentan los equipos de seguridad. Los equipos de seguridad se preocupan por el conjunto completo de certificados: descubrimiento, inventario, cumplimiento de políticas y supervisión de la caducidad de todos los certificados de todas las fuentes. Los equipos de plataforma se preocupan por un problema más específico, pero de mayor urgencia operativa: ¿cómo obtienen los desarrolladores los certificados para sus cargas de trabajo sin crear una cola en la bandeja de entrada del equipo de PKI, sin guardar secretos en los repositorios y sin generar un conjunto de certificados imposible de gestionar a gran escala?

Los patrones que los equipos de plataforma utilizan cuando PKIaaS no está disponible presentan el mismo problema: priorizan la comodidad del desarrollador a costa de la seguridad y la gestión operativa. Los certificados comodín compartidos entre servicios eliminan la gestión de certificados por servicio, pero también eliminan el aislamiento entre servicios: un servicio comprometido puede usar el comodín para suplantar la identidad de cualquier otro. Los certificados autofirmados eliminan el cuello de botella del equipo de PKI, pero también eliminan la cadena de confianza que da sentido a mTLS. Las credenciales de cuenta de servicio de larga duración ofrecen una solución provisional viable, pero generan deuda técnica: requieren eventos de rotación difíciles de coordinar en una organización de desarrolladores extensa.

La funcionalidad de PKIaaS como proveedor de identidad elimina estas desventajas. La interfaz de autoservicio facilita el trabajo del desarrollador (un recurso de certificado de cert-manager, una llamada a un módulo de Terraform, una plantilla de Backstage). La seguridad de los certificados la proporciona la CA de PKIaaS (claves respaldadas por HSM FIPS 140-3 Nivel 3, emisión regida por políticas, caducidad automática). La capa CLM facilita la gestión operativa (inventario unificado, renovación automatizada, supervisión del cumplimiento de políticas). El equipo de la plataforma configura la integración una sola vez; los desarrolladores la utilizan indefinidamente.

Integración con Kubernetes: cert-manager como interfaz del proveedor de identidad (IDP).

Para los equipos de plataforma que ejecutan proveedores de identidad (IDP) basados ​​en Kubernetes, cert-manager es la interfaz estándar entre las cargas de trabajo de los desarrolladores y la CA de PKIaaS. La arquitectura de integración consta de tres capas que el equipo de plataforma configura una sola vez.

Configuración del emisor del clúster

El equipo de la plataforma instala cert-manager en cada clúster y crea un ClusterIssuer (o varios emisores con ámbito de espacio de nombres para clústeres multiusuario con diferentes políticas de certificados por usuario) que apunta al punto final ACME de PKIaaS. La configuración del ClusterIssuer especifica la URL del servidor ACME, el ID de clave de enlace de cuenta externa (EAB) y el secreto HMAC emitidos por la CA de PKIaaS para este clúster, y la configuración del desafío DNS o HTTP para la validación del dominio. Para los servicios internos que utilizan DNS privado (que es el caso típico en un entorno Kubernetes empresarial), el desafío DNS-01 contra el proveedor DNS interno de la organización es el tipo de desafío apropiado.

Una vez configurado y validado ClusterIssuer, cada recurso de certificado en cada espacio de nombres puede referenciarlo como emisor. El equipo de la plataforma controla qué espacios de nombres pueden usar qué emisores mediante CertificateRequestPolicy de cert-manager (el componente de aprobación de políticas de cert-manager) combinado con RBAC de Kubernetes. Un espacio de nombres de aplicación podría estar restringido a solicitar certificados con SAN que coincidan con el patrón de dominio asignado al espacio de nombres; un espacio de nombres de sistema podría tener acceso a un emisor diferente que permita tipos de certificados específicos de la infraestructura.

Recursos de certificación para desarrolladores

Desde la perspectiva del desarrollador, solicitar un certificado en el IDP de Kubernetes se ve así: declarar un recurso Certificate en el gráfico Helm del servicio o en la superposición de Kustomize especificando el sujeto y los SAN deseados, hacer referencia al ClusterIssuer proporcionado por la plataforma y desplegar. cert-manager crea una CertificateRequest, envía la CSR al punto final ACME de PKIaaS, completa el desafío de validación de dominio, recupera el certificado firmado y lo almacena como un Secret de Kubernetes. La aplicación hace referencia al Secret en la especificación de su Pod como un montaje de volumen o una variable de entorno. El certificado aparece en el Pod en ejecución a los pocos segundos de aplicarse el recurso Certificate.

Cuando el certificado se acerca a su fecha de renovación (cert-manager, por defecto, lo renueva al transcurrir dos tercios de su periodo de validez), solicita automáticamente una renovación al punto final ACME de PKIaaS. El certificado renovado reemplaza al certificado que caduca en el Secret de Kubernetes. Las aplicaciones que montan el Secret como un volumen obtienen el nuevo certificado en la siguiente sincronización del sistema de archivos sin necesidad de reiniciar el pod. Las aplicaciones que almacenan en caché el valor del certificado al inicio requieren un reinicio progresivo, que cert-manager puede activar automáticamente si está configurado para ello. El desarrollador no necesita controlar las fechas de caducidad de los certificados ni recordar iniciar las renovaciones.

Controles de políticas mediante CertificateRequestPolicy

El aprobador de políticas de cert-manager agrega la capa de aplicación que transforma cert-manager, respaldado por ACME, de una herramienta de certificados conveniente a una capacidad de plataforma gobernada. Los recursos CertificateRequestPolicy definen qué solicitudes de certificados están permitidas para cada espacio de nombres o solicitante. Una política podría permitir: SAN que coincidan con el patrón *.namespace-name.svc.cluster.localTamaño de clave mínimo RSA-2048 o ECDSA-256, validez del certificado máxima de 90 días y uso extendido de clave solo para autenticación de servidor TLS y autenticación de cliente TLS. Cualquier solicitud de certificado que no coincida con una política aprobada se deniega antes de que la CSR llegue a la CA de PKIaaS. La denegación se registra, es visible para el equipo de la plataforma en el registro de auditoría del administrador de certificados y aparece en el inventario de CLM como una infracción de política.

Esto proporciona al equipo de la plataforma las medidas de seguridad necesarias para que el autoservicio sea seguro: los desarrolladores pueden solicitar cualquier certificado que cumpla con la política, sin cola de aprobación ni revisión manual. Las solicitudes que no cumplen con la política se rechazan automáticamente con un mensaje de error que indica al desarrollador qué restricción de la política ha infringido y cuál es el procedimiento correcto. El equipo de seguridad define la política; la plataforma la aplica automáticamente; los desarrolladores trabajan dentro de ella sin problemas.

Emisión de certificados para la canalización de CI/CD

Los trabajos de la canalización CI/CD requieren credenciales por un motivo distinto al de la ejecución de servicios: necesitan autenticarse en los destinos de despliegue, los registros de contenedores, los almacenes de artefactos y el servicio de firma de código PKIaaS durante el proceso de compilación. La credencial de certificado para un trabajo CI/CD debe ser válida únicamente durante la ejecución de dicho trabajo, no de forma indefinida.

Intercambio de tokens OIDC para certificados de canalización

Las plataformas CI/CD modernas emiten tokens OIDC a los trabajos de la canalización que codifican la identidad del trabajo: el repositorio, la rama, el nombre del flujo de trabajo y el entorno. Estos tokens tienen una vida útil corta y están firmados por el proveedor OIDC de la plataforma CI/CD. El equipo de la plataforma configura el punto final ACME de PKIaaS para que acepte estos tokens OIDC como credenciales de enlace de cuenta externa (EAB) mediante un flujo de intercambio de tokens: el trabajo de la canalización presenta su token OIDC a un punto final de intercambio configurado, que valida el token con el punto final JWKS de la plataforma CI/CD y emite una credencial EAB. El trabajo de la canalización utiliza esta credencial EAB para solicitar un certificado al punto final ACME de PKIaaS.

El certificado resultante es válido para el perfil de certificado de canalización configurado (normalmente de 1 a 4 horas, cubriendo el tiempo máximo de ejecución previsto de la canalización). El certificado codifica la identidad de la canalización en su sujeto (el repositorio y el flujo de trabajo en el campo URI CN o SAN). Cuando el trabajo de la canalización utiliza este certificado para autenticarse en los destinos de implementación o los servicios de firma, estos sistemas pueden verificar la identidad de la canalización a partir del certificado y tomar decisiones de autorización en función del repositorio y el flujo de trabajo en ejecución. El certificado caduca automáticamente al finalizar el trabajo. No se requiere rotación de secretos: no hay credenciales de larga duración que rotar, ya que no se emiten credenciales de larga duración.

Certificados de firma de código para artefactos de canalización

La misma CA de PKIaaS que emite certificados de servicio y certificados de identidad de canalización también puede emitir certificados de firma de código para firmar imágenes de contenedores, binarios, paquetes y manifiestos de despliegue producidos por la canalización de CI/CD. El equipo de la plataforma configura un perfil de certificado de firma de código independiente en la CA de PKIaaS (con el OID de uso de clave extendida de firma de código 1.3.6.1.5.7.3.3) y lo expone a través de la API REST de PKIaaS o un servicio de firma dedicado. Los trabajos de la canalización que producen artefactos solicitan un certificado de firma a través de este perfil, firman sus artefactos y el certificado caduca cuando finaliza el trabajo. Los controladores de admisión de Kubernetes (controlador de políticas de Sigstore, OPA/Gatekeeper con políticas de verificación de imágenes) pueden verificar las firmas de las imágenes de contenedores con la raíz de confianza de la CA de PKIaaS antes de permitir el despliegue, lo que garantiza que solo las imágenes firmadas por trabajos de canalización autorizados se admitan en el clúster.

Integración de infraestructura como código

No todas las cargas de trabajo en una plataforma de identidad empresarial se ejecutan en Kubernetes. Las máquinas virtuales, los servicios en hardware físico, las funciones sin servidor y los dispositivos de red requieren certificados, y sus equipos de plataforma suelen gestionar la infraestructura mediante Terraform, Pulumi o Ansible, en lugar de manifiestos de Kubernetes. PKIaaS expone una API REST que las herramientas de infraestructura como código pueden consumir directamente.

Para los proveedores de identidad (IDP) basados ​​en Terraform, el motor de secretos PKI de HashiCorp Vault se puede configurar para usar PKIaaS como CA ascendente, exponiendo un montaje PKI de Vault que los recursos de Terraform consumen a través del proveedor de Terraform de Vault. El equipo de la plataforma gestiona la configuración de Vault y la integración de la CA de PKIaaS; los módulos de Terraform que escriben los equipos de aplicaciones consumen el montaje PKI de Vault sin conocer la CA de PKIaaS subyacente. La emisión del certificado se realiza como parte de la aplicación de Terraform: la definición del recurso especifica los parámetros de certificado deseados, Vault emite el certificado desde su montaje PKI respaldado por PKIaaS, y el certificado se almacena en el almacén de secretos de Vault. El estado de Terraform hace referencia a la ruta del secreto de Vault; la clave privada del certificado real nunca se escribe en el estado de Terraform ni en un sistema de control de versiones.

Para el aprovisionamiento basado en Ansible, la API REST de PKIaaS se puede llamar directamente desde las tareas de Ansible utilizando el uri El equipo de la plataforma proporciona un rol estandarizado de Ansible que encapsula la API de emisión de certificados PKIaaS y gestiona la generación de claves, la construcción de CSR, el envío y el almacenamiento de certificados en una ruta estándar en el host aprovisionado. Los equipos de aplicaciones incluyen este rol en sus playbooks con parámetros que especifican el tipo de certificado deseado (que se corresponde con un perfil de certificado PKIaaS); el rol se encarga del resto.

Integración de Backstage y del catálogo de servicios

Muchos equipos de plataformas consolidadas utilizan un portal para desarrolladores (Backstage es la opción de código abierto más extendida) como interfaz de usuario para el proveedor de identidad (IDP). Para los equipos de desarrollo que prefieren un flujo de solicitudes basado en interfaz de usuario en lugar de escribir manifiestos de Kubernetes o código Terraform, la funcionalidad de emisión de certificados PKIaaS puede estar disponible en el catálogo de servicios como una plantilla de software.

Una plantilla de software de Backstage para la emisión de certificados presenta al desarrollador un formulario: seleccione el tipo de certificado (de un menú desplegable de plantillas aprobadas), ingrese el nombre del servicio (que completa el CN ​​y el SAN de DNS según la política de nomenclatura del equipo), seleccione el entorno de implementación (que determina la CA emisora ​​y el período de validez). Al enviar el formulario, se activa una acción de andamiaje que crea el recurso Certificado de cert-manager (o el archivo de variables de Terraform, o la invocación del playbook de Ansible) en el repositorio GitOps del equipo mediante una solicitud de extracción. El desarrollador aprueba la solicitud de extracción; la canalización de GitOps implementa el recurso Certificado; cert-manager emite el certificado desde PKIaaS. La interacción del desarrollador con PKI se reduce a completar un formulario de dos minutos. La plataforma aplica la política de certificados del equipo de seguridad en segundo plano.

El catálogo de servicios de Backstage también puede mostrar información sobre el estado de los certificados de los servicios registrados. Un complemento de Backstage conectado a la capa CLM puede mostrar el inventario de certificados de cada servicio, las fechas de vencimiento actuales, el estado de renovación y cualquier infracción de políticas en la página de entidad de Backstage del servicio. Los desarrolladores obtienen visibilidad del estado de los certificados de su servicio sin salir del portal de desarrolladores, y el equipo de seguridad obtiene la misma visibilidad desde el panel centralizado de la plataforma CLM sin necesidad de consultar a los desarrolladores sobre el estado de sus certificados.

Diseño de plantillas de certificados para equipos de plataforma

El diseño de la plantilla de certificado es la decisión de seguridad más importante en la integración de PKIaaS del equipo de la plataforma. Las plantillas determinan qué certificados emitirá la plataforma; la política determina qué certificados no emitirá. Un conjunto de plantillas bien diseñado para un proveedor de identidad empresarial (IDP) suele incluir las siguientes categorías:

Certificado TLS de servicio interno. Se utiliza para puntos finales HTTPS en servicios internos que no necesitan ser confiables para clientes externos. Asunto CN: service-name.namespace.svc.cluster.localSAN: SAN DNS que coincide con el nombre DNS del servicio Kubernetes y, opcionalmente, con la dirección IP del pod como SAN IP. Clave: ECDSA P-256 o RSA-2048. Validez: 90 días. EKU: Autenticación de servidor TLS. Las renovaciones automáticas las gestiona cert-manager.

Certificado de cliente mTLS (identidad de servicio). Utilizado por servicios que realizan llamadas salientes a otros servicios que requieren autenticación TLS mutua. CN del sujeto: nombre de identidad del servicio. SAN de la URI: ID de SPIFFE si se utiliza SPIFFE. Clave: ECDSA P-256. Validez: de 24 a 48 horas (de corta duración, ajustada al ciclo de vida del contenedor). EKU: Autenticación de cliente TLS. Renovación automática mediante cert-manager o SPIRE.

Certificado de trabajo de canalización CI/CD. Utilizado por los trabajos de canalización para autenticarse en los destinos de despliegue y los servicios de firma. CN del sujeto: identificador del repositorio y del flujo de trabajo. SAN de la URI: declaración del sujeto OIDC del trabajo de canalización. Clave: ECDSA P-256. Validez: de 1 a 4 horas. EKU: Autenticación de cliente TLS. Emitido mediante intercambio de tokens OIDC al inicio de la canalización, caduca al finalizar la misma.

Certificado TLS con acceso a Internet. Se utiliza para servicios que requieren la confianza de clientes externos. CN del sujeto: nombre de dominio público. SAN: todos los nombres de dominio públicos aplicables. Clave: ECDSA P-256 o RSA-2048. Validez: alineada con el calendario SC-081v3 del Foro CA/B (200 días hasta el 15 de marzo de 2026; 100 días hasta el 15 de marzo de 2027; 47 días a partir del 15 de marzo de 2029). EKU: Autenticación de servidor TLS. Renovación automática mediante cert-manager. Esta plantilla requiere una CA emisora ​​de confianza pública o una certificación cruzada con una raíz de CA pública, ya que los certificados de CA privados no son de confianza para los navegadores públicos.

Certificado de firma de código. Utilizado por los trabajos de la canalización para firmar imágenes de contenedores, binarios y manifiestos de despliegue. CN del sujeto: la identidad de la canalización o del equipo. Clave: RSA-4096 o ECDSA P-384 (mayor seguridad que los certificados de servicio). Validez: de 1 a 4 horas. EKU: Firma de código (OID 1.3.6.1.5.7.3.3). El acceso está restringido a las canalizaciones de firma autorizadas por CertificateRequestPolicy.

Visibilidad de auditoría e integración del equipo de seguridad

La emisión de certificados de autoservicio plantea una cuestión de auditoría: si cualquier desarrollador puede solicitar un certificado a través de la plataforma, ¿cómo sabe el equipo de seguridad qué certificados se han emitido y si la emisión cumplió con las políticas establecidas? La respuesta reside en la capa CLM conectada a la CA de PKIaaS.

Cada evento de emisión de certificados a través de los puntos finales de PKIaaS expuestos a la plataforma se registra en el registro de auditoría de PKIaaS con la CA emisora, el sujeto del certificado y los SAN, la identidad solicitante (la cuenta de servicio cert-manager, el sujeto OIDC de la canalización o el espacio de trabajo de Terraform) y la marca de tiempo. La plataforma CLM conectada a la CA de PKIaaS proporciona al equipo de seguridad una vista unificada de todo el conjunto de certificados en todos los inquilinos de la plataforma: qué servicios tienen certificados, cómo son sus perfiles de vencimiento, qué certificados están próximos a renovarse y qué solicitudes de certificados fueron denegadas por la política.

Para el equipo de seguridad, esto supone una mejora sustancial respecto a la alternativa (falta de visibilidad de los certificados emitidos por los desarrolladores y dependencia del escaneo de red para determinar qué se ha implementado realmente). Para el equipo de la plataforma, proporciona la base de evidencia para las auditorías de cumplimiento: cada certificado del entorno puede rastrearse hasta una solicitud de emisión autenticada a través de la plataforma, en lugar de tener un origen desconocido.

La integración de SIEM desde la plataforma CLM envía eventos del ciclo de vida de los certificados (emisión, renovación, advertencias de vencimiento, infracciones de políticas, eventos de revocación) al sistema de monitorización de seguridad junto con otros eventos de infraestructura. Una alerta de vencimiento para un certificado de servicio aparece en el mismo panel de SIEM que un intento de inicio de sesión fallido o una conexión de red anómala, lo que proporciona al equipo de seguridad visibilidad contextual sobre el riesgo de los certificados sin necesidad de una consola de gestión de certificados independiente.

Diseño multiclúster y multientorno

Las plataformas de identidad empresariales suelen abarcar varios clústeres de Kubernetes (desarrollo, pruebas, producción, clústeres específicos de cada región) y varios entornos de despliegue (nube pública, local, periferia). El diseño de la jerarquía de CA de PKIaaS debe tener en cuenta esta topología.

El diseño recomendado utiliza una única CA raíz de PKIaaS con CA emisoras específicas para cada entorno: una CA emisora ​​de desarrollo para todos los clústeres de desarrollo, una CA emisora ​​de preproducción para todos los clústeres de preproducción y una o más CA emisoras de producción para los clústeres de producción (posiblemente CA emisoras específicas de la región para los requisitos de residencia de datos). Cada CA emisora ​​tiene su propio perfil de certificado configurado según el entorno. La CA del entorno de desarrollo puede permitir períodos de validez más largos y restricciones de nomenclatura menos estrictas, ya que la expiración de los certificados en desarrollo genera fricción entre los desarrolladores. La CA del entorno de producción impone períodos de validez más cortos y restricciones de nomenclatura estrictas, ya que la expiración de los certificados en producción provoca incidentes que afectan a los usuarios.

El aislamiento del entorno mediante la jerarquía de CA implica que un certificado emitido por la CA emisora ​​de desarrollo no puede autenticarse en un servicio de producción. El almacén de confianza del servicio de producción contiene únicamente el certificado de la CA emisora ​​de producción (no el de desarrollo), aunque ambos se encadenen a la misma raíz. Este es un control técnico para limitar el alcance de las vulnerabilidades en el entorno de desarrollo: un clúster de desarrollo comprometido no puede utilizarse para suplantar la identidad de un servicio de producción, incluso si el atacante obtiene un certificado del entorno de desarrollo.

Validez del certificado de 47 días e ingeniería de la plataforma

La propuesta SC-081v3 del Foro CA/B, aprobada en abril de 2025, establece el siguiente calendario para la validez máxima de los certificados TLS de confianza pública: 200 días a partir del 15 de marzo de 2026; 100 días a partir del 15 de marzo de 2027; y 47 días a partir del 15 de marzo de 2029. Para los equipos de plataforma que gestionan un gran conjunto de certificados basados ​​en Kubernetes, esto implica la necesidad de automatización: los certificados que se renuevan cada 47 días no pueden gestionarse manualmente. El único modelo operativo viable es la renovación automatizada mediante cert-manager o un controlador equivalente.

Los equipos de plataforma que integran la automatización de cert-manager con respaldo de PKIaaS en el IDP ahora están implementando la solución de cumplimiento de 47 días como resultado de resolver el problema inmediato del autoservicio para desarrolladores. Cada recurso de certificado declarado en el manifiesto de Kubernetes de un desarrollador es administrado automáticamente por cert-manager, que lo renueva antes de su vencimiento, independientemente del período de validez. La transición de certificados de 90 días a 47 días solo requiere un cambio en el período de validez del perfil del certificado en la configuración de PKIaaS CA y CertificateRequestPolicy. La interfaz para desarrolladores (la declaración del recurso de certificado en el gráfico de Helm) no cambia. La transición de cumplimiento es un cambio de configuración de la plataforma, no un proyecto de migración de desarrolladores.

Cómo puede ayudar la consultoría de cifrado

• Infraestructura de clave pública como servicio: Consultoría de cifrado Oferta de PKIaaS Proporciona el backend de CA gobernado para la emisión de certificados IDP: ACME+EAB para la configuración de ClusterIssuer de cert-manager, API REST para la integración con Terraform y Ansible, soporte para el intercambio de tokens OIDC para la emisión de certificados de canalización CI/CD, perfiles de certificado para cada categoría de carga de trabajo (TLS de servicio, identidad de cliente mTLS, trabajos de canalización, firma de código) y CA emisoras específicas del entorno para topologías IDP de clúster múltiple. Contáctenos en Consultoría de cifrado para analizar la arquitectura de certificados de su proveedor de identidad.
• Administrador de CertSecure: Consultoría de cifrado Administrador de CertSecure Proporciona la capa de visibilidad de CLM para el equipo de plataforma y el equipo de seguridad: inventario unificado de certificados en todos los clústeres y entornos, descubrimiento de recursos de certificados de cert-manager, supervisión de caducidad con umbrales de alerta configurables, informes de cumplimiento de políticas (que señalan los certificados que infringen las restricciones de plantilla establecidas por la plataforma) e integración SIEM para fuentes de eventos del ciclo de vida de los certificados. Los complementos de backstage que muestran los datos de CertSecure Manager en el portal del desarrollador permiten la visibilidad del estado de los certificados por servicio sin salir del portal.
• CodeSign Secure: Para los equipos de plataforma que exponen la firma de código como una capacidad de IDP, Encryption Consulting CodeSign seguro Proporciona la infraestructura de firma de código basada en HSM que las canalizaciones de CI/CD utilizan para firmar imágenes de contenedores, binarios y manifiestos de despliegue. Las claves de firma se almacenan en HSM FIPS 140-3 de nivel 3; cada evento de firma se registra en el registro de auditoría; las políticas de firma restringen qué canalizaciones pueden firmar qué tipos de artefactos. La integración con los controladores de admisión de Kubernetes (Sigstore Policy Controller) permite la verificación de firmas como puerta de acceso en todos los despliegues de clúster.
• Servicios PKI: Para los equipos de plataforma que diseñan la integración de PKIaaS IDP desde cero, Encryption Consulting Servicios de PKI Proporcionar un diseño de jerarquía de CA para IDP de múltiples clústeres y entornos, un diseño de plantilla de certificado para cada categoría de carga de trabajo, configuración de CertificateRequestPolicy de cert-manager, configuración de intercambio de tokens OIDC para canalizaciones de CI/CD, patrones de integración de Terraform y Ansible, y asesoramiento sobre el complemento Backstage para la superficie de estado del certificado en el portal del desarrollador.
• Servicios de asesoramiento de PQC: Los equipos de plataforma que ahora integran la automatización de certificados respaldada por PKIaaS en el IDP también están sentando las bases para la transición de certificados post-cuánticos. Servicios de asesoramiento de PQC Integrar la planificación de emisión de certificados híbridos ML-DSA (FIPS 204) en el diseño de la plantilla de certificado del IDP, de modo que la transición a PQC sea un cambio de configuración en los perfiles PKIaaS y las plantillas de cert-manager en lugar de un proyecto de migración orientado al desarrollador.

Conclusión

La plataforma interna para desarrolladores es el lugar idóneo para resolver el problema de la gestión de certificados empresariales para las cargas de trabajo de los desarrolladores. Estos necesitan certificados y deberían poder obtenerlos mediante las mismas herramientas que utilizan para todo lo demás en la plataforma. Los equipos de seguridad necesitan visibilidad y aplicación de políticas; deberían obtenerla automáticamente desde la capa CLM de la plataforma, no mediante la revisión manual de solicitudes individuales. Los equipos de plataforma necesitan una solución escalable y mantenible; deberían obtenerla de un backend PKIaaS correctamente integrado, en lugar de una colección de scripts y secretos compartidos.

La integración no es compleja. El gestor de certificados ClusterIssuer apunta a un punto final ACME de PKIaaS. La política CertificateRequestPolicy define las medidas de seguridad. Intercambio de tokens OIDC para trabajos de canalización. Motor de secretos PKI de Vault para consumidores de Terraform. Una plantilla de Backstage para equipos que deseen una interfaz de usuario. Todos estos son patrones estándar de ingeniería de plataforma, y ​​PKIaaS es el backend de CA gobernado que los hace funcionar sin generar una deuda de seguridad que se acumule más rápido de lo que el equipo de la plataforma puede saldarla.

El plazo de validez de 47 días para los certificados del Foro CA/B hace que esta integración sea urgente. Los equipos de plataforma que automaticen la emisión y renovación de certificados antes de 2029 están desarrollando una funcionalidad que gestionará la transición al cumplimiento normativo sin necesidad de una migración por parte de los desarrolladores. Los equipos de plataforma que esperen están creando un proceso manual que no funcionará a la escala de 47 días.

Si su equipo de plataforma está diseñando la integración de PKIaaS para su IDP y desea validar la arquitectura, póngase en contacto con Encryption Consulting.

Esta publicación se revisa cada seis meses y cuando cert-manager, Backstage, el calendario de validez del CA/B Forum SC-081v3 o las principales plataformas IDP publican actualizaciones que afectan a los patrones de integración de la automatización de certificados.

Preguntas frecuentes

¿Cuál es el papel de PKIaaS en una plataforma interna para desarrolladores?

PKIaaS es el backend de CA gobernado que el equipo de la plataforma configura una sola vez y expone a través de interfaces IDP estándar: ClusterIssuers de cert-manager para cargas de trabajo de Kubernetes, puntos finales ACME con autenticación OIDC para trabajos de canalización de CI/CD, proveedores de Terraform para consumidores de IaC y plantillas de Backstage para solicitudes basadas en la interfaz de usuario. Los desarrolladores obtienen la emisión de certificados de autoservicio mediante herramientas familiares; la plataforma aplica automáticamente la política de certificados del equipo de seguridad en segundo plano.

¿Cómo integra cert-manager PKIaaS en un IDP basado en Kubernetes?

El equipo de la plataforma instala cert-manager y configura un ClusterIssuer que apunta al punto final ACME de PKIaaS con credenciales de enlace de cuenta externa. Los desarrolladores declaran los recursos de certificado en sus manifiestos de Kubernetes; cert-manager gestiona la emisión, almacena el certificado como un secreto de Kubernetes y lo renueva automáticamente antes de su vencimiento. La política CertificateRequestPolicy de cert-manager aplica las restricciones del perfil de certificado de la plataforma, rechazando las solicitudes que no cumplen con los parámetros aprobados antes de que la CSR llegue a la CA de PKIaaS.

¿Qué son las plantillas de solicitud de certificados en el contexto de PKIaaS e IDP?

Las plantillas de solicitud de certificados son especificaciones preconfiguradas y aprobadas por la política para cada categoría de carga de trabajo: patrones SAN permitidos, períodos de validez, algoritmos de clave y OID de EKU. Los desarrolladores seleccionan una plantilla al solicitar un certificado; la plataforma aplica las restricciones de la plantilla sin que el desarrollador necesite comprender los detalles de la política de certificados. Las plantillas se asignan a los perfiles de certificados en la CA de PKIaaS y a los recursos CertificateRequestPolicy en cert-manager.

¿Cómo debe gestionar un equipo de plataforma las solicitudes de certificados para cargas de trabajo que no se ejecutan en Kubernetes?

Para máquinas virtuales y servidores físicos: clientes ACME (certbot, acme.sh) apuntando al punto final ACME de PKIaaS. Para Terraform: motor de secretos PKI de HashiCorp Vault con PKIaaS como CA ascendente, consumido a través del proveedor de Terraform de Vault. Para Ansible: la API REST de PKIaaS llamada desde tareas de Ansible, encapsulada en un rol de plataforma estandarizado. Para dispositivos de red: puntos finales EST o SCEP. Para trabajos de canalización de CI/CD: intercambio de tokens OIDC que emite certificados de canalización de corta duración sin secretos precompartidos.

¿Qué medidas de protección deberían incorporar los equipos de plataforma en la emisión de certificados para el autoservicio de los desarrolladores?

Cinco categorías de medidas de seguridad: restricciones de nomenclatura de sujetos (patrones CN y SAN permitidos por espacio de nombres/equipo, aplicados por CertificateRequestPolicy), límites del período de validez (validez máxima por tipo de carga de trabajo), mínimos del algoritmo de clave (tamaño mínimo de clave y requisitos del algoritmo), restricciones del tipo de certificado (cada equipo/espacio de nombres solo puede solicitar tipos apropiados para su carga de trabajo; no se permiten certificados de CA ni de firma de código a través de la interfaz general del desarrollador) y visibilidad de la auditoría (todos los eventos de emisión se registran en el registro de auditoría de PKIaaS y se muestran en la plataforma CLM).