Administración de certificados en clústeres de Service Fabric

En este artículo, se tratan los aspectos de administración de los certificados que se usan para proteger la comunicación en los clústeres de Azure Service Fabric. Complementa la introducción a la seguridad del clúster de Service Fabric y al artículo que explica la autenticación basada en certificados X.509 en Service Fabric.

Requisitos previos

Antes de comenzar, debe estar familiarizado con los conceptos fundamentales de seguridad y los controles que expone Service Fabric para configurar la seguridad de un clúster.

Declinación de responsabilidades

En este artículo, se emparejan aspectos teóricos de la administración de certificados con ejemplos prácticos que cubren los detalles de los servicios, las tecnologías, etc. Como gran parte del público aquí es interno de Microsoft, el artículo hace referencia a servicios, tecnologías y productos específicos de Azure. Si ciertos detalles específicos de Microsoft no son aplicables para usted, no dude en pedir aclaraciones u orientación en la sección de comentarios del final.

Definición de la administración de certificados

Como aprenderá en el artículo complementario Autenticación basada en certificados X.509 en clústeres de Service Fabric, un certificado es un objeto criptográfico que básicamente enlaza un par de claves asimétricas con atributos que describen la entidad que representa.

Sin embargo, un certificado también es un objeto perecedero, porque su duración es finita y es susceptible a verse puesto en peligro. La divulgación accidental o una vulnerabilidad de seguridad que tenga éxito pueden hacer que un certificado sea inútil desde el punto de vista de la seguridad. Esta característica implica la necesidad de cambiar los certificados, ya sea de forma rutinaria o en respuesta a un incidente de seguridad.

Otro aspecto de la administración (y un tema completamente independiente) es la protección de las claves privadas de los certificados, o de los secretos que protegen las identidades de las entidades involucradas en la obtención y el aprovisionamiento de certificados.

Describimos la administración de certificados como los procesos y procedimientos usados para obtener certificados y para transportarlos de forma segura (y protegida) a donde sean necesarios.

Algunas operaciones de administración, como la inscripción, la configuración de directivas y los controles de autorización, están fuera del ámbito de este artículo. Otras operaciones, como el aprovisionamiento, la renovación, el cambio de clave o la revocación, solo se relacionan accidentalmente con Service Fabric. Sin embargo, el artículo los aborda un cierto modo, ya que comprender estas operaciones puede ayudarle a proteger el clúster correctamente.

Es probable que el objetivo inmediato sea automatizar la administración de certificados tanto como sea posible para garantizar la disponibilidad ininterrumpida del clúster. Dado que el proceso se realiza sin intervención del usuario, también querrá ofrecer garantías de seguridad. Con los clústeres de Service Fabric, se puede lograr este objetivo.

El resto del artículo primero deconstruye la administración de certificados y, posteriormente, se centra en habilitar la sustitución automática.

Específicamente, se tratan los temas siguientes:

• Supuestos de separación de atribuciones entre el propietario y la plataforma
• La larga canalización desde la emisión del certificado hasta el consumo
• Rotación de certificados: por qué, cómo y cuándo
• ¿Qué podría salir mal?

El artículo no trata estos temas:

• Protección y administración de nombres de dominio
• Inscripción en certificados
• Configuración de controles de autorización para aplicar la emisión de certificados.

Para obtener información sobre estos temas, consulte a la entidad de registro (RA) de su servicio de infraestructura de clave pública (PKI) favorito. Si es un lector interno de Microsoft, puede ponerse en contacto con el equipo de seguridad de Azure.

Roles y entidades involucrados en la administración de certificados

El enfoque de seguridad en un clúster de Service Fabric es de tipo "el propietario del clúster lo declara, el entorno de ejecución de Service Fabric lo aplica". Esto significa que casi ninguno de los certificados, claves u otras credenciales de las identidades que participan en el funcionamiento de un clúster proceden del propio servicio. Todos son declarados por el propietario del clúster. Además, el propietario del clúster también es responsable de aprovisionar los certificados en el clúster, renovarlos según sea necesario y ayudar a garantizar su seguridad en todo momento.

Más concretamente, el propietario del clúster debe asegurarse de lo siguiente:

• Los certificados que se declaran en la sección NodeType del manifiesto de clúster se pueden encontrar en cada nodo de ese tipo, de acuerdo con las reglas de presentación.
• Los certificados que se declaran como en el punto de viñeta anterior se instalan con sus claves privadas correspondientes incluidas.
• Los certificados que se declaran en las reglas de presentación deben pasar las reglas de validación.

Service Fabric, por su parte, asume las siguientes responsabilidades:

• Ubicar los certificados que coinciden con las declaraciones en la definición del clúster
• Conceder acceso a las claves privadas correspondientes a las entidades controladas por Service Fabric según sea necesario
• Validar los certificados en estricta conformidad con los procedimientos recomendados de seguridad establecidos y la definición del clúster
• Alertar sobre la inminente caducidad de los certificados o los fallos en la realización de los pasos básicos de validación de los mismos
• Validar (hasta cierto punto) que la configuración subyacente de los hosts cumpla los aspectos relacionados con el certificado de la definición del clúster

De esto se desprende que la carga de la administración de certificados (como operaciones activas) recae exclusivamente en el propietario del clúster. Las secciones siguientes ofrecen una visión más detallada de cada una de las operaciones de administración, con los mecanismos disponibles y su impacto en el clúster.

Recorrido de un certificado

Vamos a describir rápidamente la progresión de un certificado desde su emisión hasta su consumo en el contexto de un clúster de Service Fabric:

1. El propietario de un dominio registra en la RA de una PKI un dominio o firmante que quiere asociar a los certificados resultantes. Los certificados, a su vez, constituyen una prueba de propiedad del dominio o firmante.

2. El propietario del dominio también designa en la RA las identidades de los solicitantes autorizados, entidades que tienen derecho a solicitar la inscripción de certificados con el dominio o firmante especificado.

3. A continuación, un solicitante autorizado se inscribe en un certificado mediante un servicio de administración de secretos. En Azure, el servicio de administración de secretos elegido es Azure Key Vault, que almacena de forma segura secretos y certificados y permite su recuperación por entidades autorizadas. Key Vault también renueva el certificado y regenera sus claves según lo configurado en la directiva de certificados asociada. Key Vault usa Microsoft Entra ID como proveedor de identidades.

4. Un recuperador autorizado, o un agente de aprovisionamiento, recupera el certificado del almacén de claves, incluida su clave privada, y lo instala en las máquinas que hospedan el clúster.

5. El servicio de Service Fabric (que se ejecuta con privilegios elevados en cada nodo) concede a las entidades de Service Fabric permitidas acceso al certificado; los grupos locales designan estas entidades, que se dividen entre ServiceFabricAdministrators y ServiceFabricAllowedUsers.

6. El entorno de ejecución de Service Fabric accede al certificado y lo usa para establecer la federación, o para autenticarse en las solicitudes entrantes de clientes autorizados.

7. El agente de aprovisionamiento supervisa el certificado del almacén de claves y, cuando detecta la renovación, desencadena el flujo de aprovisionamiento. A continuación, el propietario del clúster actualiza la definición del clúster, si es necesario, para indicar la intención de sustituir el certificado.

8. El agente de aprovisionamiento o el propietario del clúster también son responsables de limpiar y eliminar los certificados sin usar.

Para los fines de este artículo, los dos primeros pasos de la secuencia anterior prácticamente no están relacionados. Su única conexión es que el nombre común del firmante del certificado es el nombre DNS que se declara en la definición del clúster.

El flujo de emisión y el aprovisionamiento de certificados se muestran en los diagramas siguientes:

Para los certificados declarados por huella digital

Para los certificados declarados por nombre común del firmante

Inscripción de certificados

El tema de la inscripción de certificados se trata en detalle en la documentación de Key Vault. Aquí se incluye una sinopsis para dar continuidad y una referencia más sencilla.

Continuando con Azure como contexto y usando Azure Key Vault como servicio de administración de secretos, un solicitante de certificados autorizado debe tener al menos permisos de administración de certificados en el almacén de claves, concedido por el propietario del almacén de claves. A continuación, el solicitante se inscribe en un certificado de la manera siguiente:

• El solicitante crea una directiva de certificado en Key Vault, que especifica el dominio o firmante del certificado, el emisor deseado, el tipo de clave y su longitud, el uso previsto de la clave, etc. Para más información, consulte Introducción a los certificados de Key Vault.

• El solicitante crea un certificado en el mismo almacén con la directiva especificada en el paso anterior. Esto, a su vez, genera un par de claves como objetos del almacén y una solicitud de firma de certificado firmada con la clave privada, que luego se reenvía al emisor designado para su firma.

• Una vez que el emisor, o la entidad de certificación (CA), responde con el certificado firmado, el resultado se combina en el almacén de claves y los datos del certificado están disponibles como se indica a continuación:

  • En {vaultUri}/certificates/{name}: el certificado, incluida la clave pública y los metadatos
  • En {vaultUri}/keys/{name}: la clave privada del certificado, disponible para las operaciones criptográficas (encapsular/desencapsular, firmar/verificar)
  • En {vaultUri}/secrets/{name}: el certificado, incluida su clave privada, disponible para su descarga como un archivo PEM o PFX sin proteger.

Recuerde que un certificado del almacén de claves contiene una lista cronológica de las instancias de certificado que comparten una directiva. Las versiones de los certificados se crearán de acuerdo con los atributos de duración y renovación de esta política. Se recomienda que los certificados del almacén no compartan firmantes ni dominios ni nombres DNS, porque puede ser perjudicial en un clúster aprovisionar instancias de certificado de distintos certificados del almacén, con firmantes idénticos, pero con otros atributos sustancialmente diferentes, como el emisor, los usos de la clave, etc. En este momento, existe un certificado en el almacén de claves, listo para su consumo. Ahora, vamos a explorar el resto del proceso.

Aprovisionamiento del certificado

Hemos mencionado un agente de aprovisionamiento, que es la entidad que recupera el certificado, incluida su clave privada, del almacén de claves y lo instala en cada uno de los hosts del clúster. (Recuerde que Service Fabric no aprovisiona los certificados).

En el contexto de este artículo, el clúster se hospedará en una colección de máquinas virtuales (VM) de Azure o en conjuntos de escalado de máquinas virtuales. En Azure, puede aprovisionar un certificado desde un almacén a una máquina virtual o un VMSS mediante los mecanismos siguientes. Aquí se supone, como antes, que el propietario del almacén de claves concedió previamente al agente de aprovisionamiento permisos de obtención de secretos en el almacén de claves.

• Ad hoc: un operador recupera el certificado del almacén de claves (como un archivo PFX/PKCS 12 o PEM) y lo instala en cada nodo.

  No se recomienda el mecanismo ad hoc por varios motivos, desde la seguridad hasta la disponibilidad, por lo que no se tratará más en adelante. Para más información, consulte Preguntas frecuentes sobre los conjuntos de escalado de máquinas virtuales de Azure.

• Como un secreto del conjunto de escalado de máquinas virtuales durante la implementación: al utilizar la identidad de la primera parte en nombre del operador, el servicio de proceso recupera el certificado de un almacén habilitado para la implementación de plantillas y lo instala en cada nodo del conjunto de escalado de máquinas virtuales, como se describe en Preguntas frecuentes sobre los conjuntos de escalado de máquinas virtuales de Azure.

  Nota

  Este enfoque solo permite el aprovisionamiento de secretos con versiones.

• Mediante el uso de la extensión de máquina virtual de Key Vault. Esto le permite aprovisionar certificados mediante declaraciones sin versión, con la actualización periódica de los certificados observados. En este caso, se espera que la VM o el VMSS tengan una identidad administrada, una identidad a la que se le ha concedido acceso a los almacenes de claves que contienen los certificados observados.

El aprovisionamiento basado en VMSS o proceso presenta ventajas de seguridad y disponibilidad, pero también presenta restricciones. Requiere, de manera predeterminada, que declare los certificados como secretos versionados. Este requisito hace que el aprovisionamiento basado en VMSS o proceso sea adecuado solo para clústeres protegidos con certificados declarados por huella digital.

Por el contrario, el aprovisionamiento basado en la extensión de máquina virtual de Key Vault siempre instalará la versión más reciente de cada certificado observado. Esto hace que sea adecuado solo para los clústeres protegidos con certificados declarados por huella digital. Para enfatizar, no use un mecanismo de aprovisionamiento de actualización automática (como la extensión de máquina virtual de Key Vault) para los certificados declarados por instancia (es decir, por huella digital). El riesgo de perder disponibilidad es considerable.

Existen otros mecanismos de aprovisionamiento, pero los enfoques mencionados aquí son las opciones aceptadas actualmente para los clústeres de Azure Service Fabric.

Consumo y supervisión de certificados

Como se mencionó anteriormente, el entorno de ejecución de Service Fabric es responsable de ubicar y usar los certificados declarados en la definición del clúster. En el artículo Autenticación basada en certificados X.509 en clústeres de Service Fabric, se explica en detalle cómo implementa Service Fabric las reglas de presentación y validación, y no se volverá a tratar aquí. En este artículo, vamos a analizar la concesión de acceso y permisos, así como la supervisión.

Recuerde que los certificados se usan en Service Fabric para una gran variedad de propósitos, desde la autenticación mutua en el nivel de federación hasta la autenticación de Seguridad de la capa de transporte (TLS) para los puntos de conexión de administración. Esto requiere que varios componentes o servicios del sistema tengan acceso a la clave privada del certificado. El entorno de ejecución de Service Fabric examina periódicamente el almacén de certificados y busca coincidencias para cada una de las reglas de presentación conocidas.

Para cada certificado coincidente, se encuentra la clave privada correspondiente y su lista de control de acceso discrecional se actualiza para incluir los permisos (lectura y ejecución, normalmente) que se conceden a la identidad que los requiere.

Este proceso se conoce de modo informal como inclusión en la ACL. El proceso se ejecuta con una cadencia de 1 minuto y también abarca los certificados de aplicación, como los que se usan para cifrar la configuración o como certificados de puntos de conexión. La inclusión en la ACL sigue las reglas de presentación, por lo que es importante tener en cuenta que no se podrá acceder a los certificados que se declaran por huella digital y que se actualizan de forma automática sin la actualización de la configuración de clúster subsiguiente.

Rotación de certificados

Nota

La RFC 3647 del Grupo de Trabajo de Ingeniería de Internet (IETF) define formalmente la renovación como la emisión de un certificado con los mismos atributos que el certificado que se va a reemplazar. Se conservan el emisor, la clave pública del firmante y la información. La generación de una nueva clave es la emisión de un certificado con un nuevo par de claves, sin restricciones sobre si el emisor puede cambiar. Dado que la distinción puede ser importante (considere el caso de los certificados declarados por nombre común del firmante con anclaje del emisor), optaremos por el término neutro rotación para abarcar ambos escenarios. Tenga en cuenta que, cuando se usa informalmente el término renovación, hace referencia a la generación de una nueva clave.

Como se mencionó anteriormente, Key Vault admite la rotación automática de certificados. Es decir, la directiva de certificados asociada define el punto en el tiempo, ya sea en días antes de la expiración o en porcentaje de la duración total, cuando se rota el certificado en el almacén de claves. Se debe invocar al agente de aprovisionamiento después de dicho momento y antes de la expiración del certificado que será el anterior, para distribuir este nuevo certificado a todos los nodos del clúster.

Para ayudar en este proceso, Service Fabric genera advertencias de estado cuando la fecha de expiración de un certificado que está actualmente en uso en el clúster se produzca antes de un intervalo predeterminado. Un agente de aprovisionamiento automático, la extensión de máquina virtual de Key Vault, que está configurado para observar el certificado del almacén de claves, sondea periódicamente el almacén de claves, detecta la rotación y recupera e instala el nuevo certificado. El aprovisionamiento que tiene lugar mediante la característica de secretos de la VM o el VMSS requiere un operador autorizado para actualizar la máquina virtual o el VMSS con el identificador URI de Key Vault con versiones que corresponde al nuevo certificado.

Ahora, se aprovisiona en todos los nodos el certificado que se ha rotado. Ahora, suponiendo que la rotación aplicada al certificado del clúster se haya declarado por el nombre común del firmante, vamos a examinar lo que sucede a continuación:

• En el caso de las nuevas conexiones dentro del clúster, así como con el clúster, el entorno de ejecución de Service Fabric busca y selecciona el certificado coincidente emitido más recientemente (el valor mayor de la propiedad NotBefore). Se trata de un cambio con respecto a las versiones anteriores del entorno de ejecución de Service Fabric.

• Las conexiones existentes se mantendrán activas o permitidas hasta la expiración natural o, de lo contrario, hasta que finalicen, y un controlador interno recibirá una notificación de que existe una nueva coincidencia.

Nota

Actualmente, a partir de la versión 7.2 CU4+, Service Fabric selecciona el certificado con el mayor valor de la propiedad NotBefore (emitido más recientemente). Antes de la versión 7.2 CU4, Service Fabric seleccionaba el certificado válido con el valor mayor de NotAfter (expiración más reciente).

Esto se traduce en las siguientes observaciones importantes:

• La disponibilidad del clúster, o de las aplicaciones hospedadas, tiene prioridad sobre la directiva de rotación del certificado. El clúster convergerá finalmente en el nuevo certificado, pero sin garantías de tiempos. Así pues:

  • Puede que a un observador no le resulte inmediatamente evidente que el certificado rotado ha sustituido por completo a su predecesor. La única manera de forzar la sustitución inmediata del certificado actualmente en uso es reiniciar las máquinas host. No basta con reiniciar los nodos de Service Fabric, ya que los componentes de modo kernel que forman las conexiones de concesión en un clúster no se verán afectados. Además, el reinicio de la VM o el VMSS puede provocar una pérdida temporal de disponibilidad. En el caso de los certificados de aplicación, basta con reiniciar solo las instancias de aplicación correspondientes.

  • La introducción de un certificado con una clave regenerada que no cumple las reglas de validación puede interrumpir verdaderamente el clúster. El ejemplo más común es el caso de un emisor inesperado, en el que los certificados del clúster se declaran por nombre común del firmante con anclaje del emisor, pero un emisor nuevo o no declarado ha emitido el certificado rotado.

Limpieza de certificados

En este momento, no hay ninguna disposición en Azure para la eliminación explícita de certificados. A menudo, determinar si un certificado determinado está en uso o no en un momento específico es una tarea que no es trivial. Esto es más difícil para los certificados de aplicación que para los certificados de clúster. Service Fabric, al no ser el agente de aprovisionamiento, no eliminará un certificado declarado por el usuario en ningún caso. Para los mecanismos de aprovisionamiento estándar:

• Los certificados declarados como secretos de VM o VMSS se aprovisionan siempre y cuando se haga referencia a ellos en la definición de la VM o el VMSS y se puedan recuperar desde el almacén de claves. La eliminación de un secreto o certificado del almacén de claves producirá un error en las implementaciones posteriores de la VM o el VMSS. De forma similar, al deshabilitar una versión del secreto en el almacén de claves, también se producirá un error en las implementaciones de la VM o el VMSS que hagan referencia a la versión del secreto.

• Las versiones anteriores de los certificados que se aprovisionan mediante la extensión de máquina virtual de Key Vault podrían estar presentes o no en una VM o un nodo del VMSS. El agente solo recupera e instala la versión actual y no quita ningún certificado. Restablecer la imagen inicial de un nodo, lo que habitualmente suele producirse cada mes, restablece el almacén de certificados al contenido de la imagen del sistema operativo, por lo que las versiones anteriores se quitarán implícitamente. Sin embargo, tenga en cuenta que, al escalar verticalmente un conjunto de escalado de máquinas virtuales, solo se instalará la versión actual de los certificados observados. No suponga la homogeneidad de los nodos con respecto a los certificados instalados.

Simplificación de la administración: ejemplo de sustitución automática

Hasta el momento, este artículo ha descrito mecanismos y restricciones, ha esbozado reglas y definiciones intrincadas, y ha hecho predicciones graves sobre las interrupciones. Ahora es el momento de configurar la administración automática de certificados para evitar todas estas inquietudes. Vamos a hacerlo en el contexto de un clúster de Azure Service Fabric que se ejecuta en un conjunto de escalado de máquinas virtuales de la versión v2, con Azure Key Vault para la administración de secretos y aprovechando las identidades administradas, como se indica a continuación:

• La validación de certificados se ha cambiado del anclaje de huella digital al anclaje de firmante y emisor. Cualquier certificado con un firmante específico de un emisor específico es igualmente de confianza.
• Los certificados se inscriben y se obtienen de un almacén de confianza (Key Vault) y se actualizan mediante un agente (en este caso, la extensión de máquina virtual de KeyVault).
• El aprovisionamiento de certificados se ha cambiado de uno basado en el momento de la implementación y la versión (como lo hace el proveedor de recursos Azure Compute) a uno posterior a la implementación mediante los identificadores URI de Key Vault sin versión.
• El acceso al almacén de claves se concede mediante identidades administradas asignadas por el usuario, que se crean y se asignan al conjunto de escalado de máquinas virtuales durante la implementación.
• Después de la implementación, el agente (la extensión de máquina virtual de Key Vault) sondea y actualiza los certificados observados en cada nodo del conjunto de escalado de máquinas virtuales. Por lo tanto, la rotación de certificados está totalmente automatizada, ya que Service Fabric recoge automáticamente el certificado válido más reciente.

La secuencia se puede escribir como un script y automatizar en su totalidad, y permite, sin intervención del usuario, una implementación inicial de un clúster configurado para la sustitución automática de certificados. En las secciones siguientes, se proporcionan pasos detallados que contienen una combinación de cmdlets de PowerShell y fragmentos de plantillas JSON. La misma funcionalidad puede lograrse con todos los medios admitidos para interactuar con Azure.

Nota:

En este ejemplo, se supone que ya existe un certificado en el almacén de claves. La inscripción y renovación de un certificado administrado por Key Vault requiere pasos manuales de requisitos previos, como se ha descrito anteriormente en este artículo. Para entornos de producción, use certificados administrados por Key Vault. Hemos incluido un script de ejemplo específico de una PKI interna de Microsoft.

Nota

La sustitución automática de certificados solo tiene sentido para los certificados emitidos por una CA. El uso de certificados autofirmados, incluidos los generados durante la implementación de un clúster de Service Fabric en Azure Portal, no tiene sentido, pero sigue siendo posible para implementaciones locales u hospedadas por el desarrollador si declara que la huella digital del emisor es la misma que la del certificado hoja.

Punto de partida

Por motivos de brevedad, supondremos el siguiente estado de partida:

• El clúster de Service Fabric existe y está protegido con un certificado emitido por una entidad de certificación, declarado por huella digital.
• El certificado se almacena en un almacén de claves y se aprovisiona como un secreto de un conjunto de escalado de máquinas virtuales.
• El mismo certificado se usará para convertir el clúster en declaraciones de certificado basadas en el nombre común, por lo que el firmante y el emisor pueden validarlo. Si este no es el caso, obtenga el certificado emitido por la CA destinado a este propósito y agréguelo a la definición del clúster mediante huella digital. Este proceso se explica en Agregar o quitar certificados para un clúster de Service Fabric de Azure.

Este es un extracto de código JSON de una plantilla que corresponde a este estado. El extracto omite muchas configuraciones necesarias e ilustra solo los aspectos relacionados con el certificado.

  "resources": [
    {   ## VMSS definition
      "apiVersion": "[variables('vmssApiVersion')]",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "[variables('vmNodeTypeName')]",
      "location": "[variables('computeLocation')]",
      "properties": {
        "virtualMachineProfile": {
          "extensionProfile": {
            "extensions": [
            {
                "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
                "properties": {
                  "type": "ServiceFabricNode",
                  "autoUpgradeMinorVersion": true,
                  "publisher": "Microsoft.Azure.ServiceFabric",
                  "settings": {
                    "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
                    "nodeTypeRef": "[variables('vmNodeTypeName')]",
                    "dataPath": "D:\\SvcFab",
                    "durabilityLevel": "Bronze",
                    "certificate": {
                        "thumbprint": "[parameters('primaryClusterCertificateTP')]",
                        "x509StoreName": "[parameters('certificateStoreValue')]"
                    }
                  },
                  "typeHandlerVersion": "1.1"
                }
            },}},
          "osProfile": {
            "adminPassword": "[parameters('adminPassword')]",
            "adminUsername": "[parameters('adminUsername')]",
            "secrets": [
            {
                "sourceVault": {
                    "id": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
                },
                "vaultCertificates": [
                {
                    "certificateStore": "[parameters('certificateStoreValue')]",
                    "certificateUrl": "[parameters('clusterCertificateUrlValue')]"
                },
            ]}]
        },
    },
    {   ## cluster definition
        "apiVersion": "[variables('sfrpApiVersion')]",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "certificate": {
            "thumbprint": "[parameters('primaryClusterCertificateTP')]",
            "x509StoreName": "[parameters('certificateStoreValue')]"
        },
    }
  ]

En esencia, el código anterior indica que el certificado con la huella digital json [parameters('primaryClusterCertificateTP')] y que se encuentra en el identificador URI de Key Vault json [parameters('clusterCertificateUrlValue')] se declara como el certificado único del clúster, por huella digital.

A continuación, vamos a configurar los recursos adicionales necesarios para asegurar la sustitución automática del certificado.

Configuración de los recursos de los requisitos previos

Como se mencionó anteriormente, el servicio del proveedor de recursos Microsoft Compute recupera del almacén de claves un certificado aprovisionado como un secreto del conjunto de escalado de máquinas virtuales. Lo hace mediante su identidad de primera entidad en nombre del operador de implementación. Ese proceso cambiará para la sustitución automática. Cambiará al uso de una identidad administrada asignada al conjunto de escalado de máquinas virtuales y a la que se le han concedido permisos GET en los secretos de ese almacén.

Debe implementar los siguientes extractos al mismo tiempo. Solo se enumeran individualmente para el análisis y la explicación por partes.

En primer lugar, defina una identidad asignada por el usuario (los valores predeterminados se incluyen como ejemplos). Para más información, consulte la documentación oficial.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "userAssignedIdentityName": {
      "type": "string",
      "defaultValue": "sftstuaicus",
      "metadata": {
        "description": "User-assigned managed identity name"
      }
    },
  },
  "variables": {
      "vmssApiVersion": "2018-06-01",
      "sfrpApiVersion": "2018-02-01",
      "miApiVersion": "2018-11-30",
      "kvApiVersion": "2018-02-14",
      "userAssignedIdentityResourceId": "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentityName'))]"
  },    
  "resources": [
    {
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
      "name": "[parameters('userAssignedIdentityName')]",
      "apiVersion": "[variables('miApiVersion')]",
      "location": "[resourceGroup().location]"
    },
  ]}

A continuación, conceda a esta identidad acceso a los secretos del almacén de claves. Para obtener la información más reciente, consulte la documentación oficial.

  "resources":
  [{
      "type": "Microsoft.KeyVault/vaults/accessPolicies",
      "name": "[concat(parameters('keyVaultName'), '/add')]",
      "apiVersion": "[variables('kvApiVersion')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).tenantId]",
            "objectId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).principalId]",
            "dependsOn": [
              "[variables('userAssignedIdentityResourceId')]"
            ],
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]}}]}}]

En el próximo paso, hará lo siguiente:

• Asignar al conjunto de escalado de máquinas virtuales la identidad asignada por el usuario.
• Declarar la dependencia del conjunto de escalado de máquinas virtuales en la creación de la identidad administrada y en el resultado de concederle acceso al almacén.
• Declarar la extensión de máquina virtual de Key Vault y requerir que recupere los certificados observados durante el inicio. Para más información, consulte la documentación oficial de la extensión de máquina virtual de Key Vault para Windows.
• Actualizar la definición de la extensión de máquina virtual de Service Fabric para que dependa de la extensión de máquina virtual de Key Vault y convertir la declaración de certificado del clúster de huella digital a nombre común.

Nota

Estos cambios se realizan como un solo paso porque se encuentran dentro del ámbito del mismo recurso.

  "parameters": {
    "kvvmextPollingInterval": {
      "type": "string",
      "defaultValue": "3600",
      "metadata": {
        "description": "kv vm extension polling interval in seconds"
      }
    },
    "kvvmextLocalStoreName": {
      "type": "string",
      "defaultValue": "MY",
      "metadata": {
        "description": "kv vm extension local store name"
      }
    },
    "kvvmextLocalStoreLocation": {
      "type": "string",
      "defaultValue": "LocalMachine",
      "metadata": {
        "description": "kv vm extension local store location"
      }
    },
    "kvvmextObservedCertificates": {
      "type": "array",
      "defaultValue": [
                "https://sftestcus.vault.azure.net/secrets/sftstcncluster",
                "https://sftestcus.vault.azure.net/secrets/sftstcnserver"
            ],
      "metadata": {
        "description": "kv vm extension observed certificates versionless uri"
      }
    },
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
  },
  "resources": [
  {
    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
    "name": "[variables('vmNodeTypeName')]",
    "location": "[variables('computeLocation')]",
    "dependsOn": [
      "[variables('userAssignedIdentityResourceId')]",
      "[concat('Microsoft.KeyVault/vaults/', concat(parameters('keyVaultName'), '/accessPolicies/add'))]"
    ],
    "identity": {
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "[variables('userAssignedIdentityResourceId')]": {}
      }
    },
    "virtualMachineProfile": {
      "extensionProfile": {
        "extensions": [
        {
          "name": "KVVMExtension",
          "properties": {
            "publisher": "Microsoft.Azure.KeyVault",
            "type": "KeyVaultForWindows",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "settings": {
                "secretsManagementSettings": {
                    "pollingIntervalInS": "[parameters('kvvmextPollingInterval')]",
                    "linkOnRenewal": false,
                    "observedCertificates": "[parameters('kvvmextObservedCertificates')]",
                    "requireInitialSync": true
                }
            }
          }
        },
        {
        "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
        "properties": {
          "type": "ServiceFabricNode",
          "provisionAfterExtensions" : [ "KVVMExtension" ],
          "publisher": "Microsoft.Azure.ServiceFabric",
          "settings": {
            "certificate": {
                "commonNames": [
                    "[parameters('certificateCommonName')]"
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            }
            },
            "typeHandlerVersion": "1.0"
          }
        },
  ] } ## extension profile
  },  ## VM profile
  "osProfile": {
    "adminPassword": "[parameters('adminPassword')]",
    "adminUsername": "[parameters('adminUsername')]",
  } 
  }
  ]

Aunque no aparece explícitamente en el código anterior, tenga en cuenta que la dirección URL del certificado del almacén de claves se ha quitado de la sección OsProfile del conjunto de escalado de máquinas virtuales.

El último paso es actualizar la definición del clúster para cambiar la declaración del certificado de huella digital a nombre común. También anclamos las huellas digitales del emisor:

  "parameters": {
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
    "certificateIssuerThumbprint": {
      "type": "string",
      "defaultValue": "1b45ec255e0668375043ed5fe78a09ff1655844d,d7fe717b5ff3593764f4d90654d86e8362ec26c8,3ac7c3cac8de0dd392c02789c8be97474f456960,96ea05926e2e42cc207e358668be2c316857fb5e",
      "metadata": {
        "description": "Certificate issuer thumbprints separated by comma"
      }
    },
  },
  "resources": [
    {
      "apiVersion": "[variables('sfrpApiVersion')]",
      "type": "Microsoft.ServiceFabric/clusters",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('clusterLocation')]",
      "properties": {
        "certificateCommonNames": {
          "commonNames": [{
              "certificateCommonName": "[parameters('certificateCommonName')]",
              "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
          }],
          "x509StoreName": "[parameters('certificateStoreValue')]"
        },
  ]

En este momento, puede ejecutar las actualizaciones mencionadas anteriormente en una sola implementación. Por su parte, el servicio del proveedor de recursos de Service Fabric divide la actualización del clúster en varios pasos, como se describe en el segmento sobre conversión de los certificados de un clúster de huella digital a nombre común.

Análisis y observaciones

Esta sección es un cajón de sastre para explicar conceptos y procesos que se han presentado a lo largo de este artículo, así como para llamar la atención sobre algunos otros aspectos importantes.

Acerca del aprovisionamiento de certificados

La extensión de máquina virtual de Key Vault, como agente de aprovisionamiento, se ejecuta de forma continua con una frecuencia predeterminada. Si no puede recuperar un certificado observado, continúa con el siguiente en la línea y, a continuación, hiberna hasta el siguiente ciclo. La extensión de máquina virtual de Service Fabric, como agente de arranque del clúster, requiere los certificados declarados antes de que se pueda formar el clúster. Esto, a su vez, significa que la extensión de máquina virtual de Service Fabric solo se puede ejecutar después de la recuperación correcta de los certificados del clúster, que se indica aquí mediante la cláusula json "provisionAfterExtensions" : [ "KVVMExtension" ]" y mediante la configuración json "requireInitialSync": true de la extensión de máquina virtual de Key Vault.

Esto indica a la extensión de máquina virtual de Key Vault que en la primera ejecución (después de la implementación o de un reinicio) debe recorrer los certificados observados hasta que todos se hayan descargado correctamente. Si se establece este parámetro en false, acompañado de un error al recuperar los certificados del clúster, se producirá un error en la implementación del clúster. Por el contrario, si se requiere una sincronización inicial con una lista incorrecta o no válida de certificados observados, se producirá un error de la extensión de máquina virtual de Key Vault y, por lo tanto, nuevamente un error al implementar el clúster.

Explicación de la vinculación de certificados

Es posible que haya observado la marca linkOnRenewal de la extensión de máquina virtual de Key Vault y el hecho de que se ha establecido en false. Esta configuración aborda el comportamiento que controla esta marca y sus consecuencias en el funcionamiento de un clúster. Este comportamiento es específico de Windows.

Según su definición:

"linkOnRenewal": <Only Windows. This feature enables auto-rotation of SSL certificates, without necessitating a re-deployment or binding. e.g.: false>,

Los certificados utilizados para establecer una conexión TLS normalmente se adquieren como un manipulador mediante el proveedor de apoyo de seguridad S-channel. Es decir, el cliente no accede directamente a la clave privada del propio certificado. S-channel admite el redireccionamiento, o la vinculación, de credenciales en forma de extensión de certificado, CERT_RENEWAL_PROP_ID.

Si se establece esta propiedad, su valor representa la huella digital del certificado de renovación, por lo que S-channel intentará cargar el certificado vinculado. De hecho, S-channel recorrerá esta lista vinculada (y, esperemos, acíclica) hasta que acabe con el certificado final, uno sin una marca de renovación. Esta característica, si se usa con prudencia, es una excelente mitigación de la pérdida de disponibilidad causada por los certificados expirados, por ejemplo.

En otros casos, puede ser la causa de interrupciones difíciles de diagnosticar y mitigar. S-channel ejecuta el recorrido de los certificados en sus propiedades de renovación de manera incondicional, independientemente del firmante, los emisores o cualquier otro atributo específico que participe en la validación del certificado resultante por parte del cliente. Es posible que el certificado resultante no tenga ninguna clave privada asociada o que la clave no se haya incluido en la ACL para su consumidor potencial.

Si la vinculación está habilitada, la extensión de máquina virtual de Key Vault, cuando recupera un certificado observado del almacén de claves, intentará encontrar los certificados existentes coincidentes para vincularlos mediante la propiedad de extensión de renovación. La coincidencia se basa exclusivamente en el nombre alternativo del firmante (SAN) y funciona, si hay dos certificados existentes, como se muestra en los ejemplos siguientes: A: Nombre del certificado (CN) = "Accesorios de Alice", SAN = {"alice.universalexports.com"}, renovación = "" B: CN = "Bits de Bob", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, renovación = ""

Suponga que la extensión de máquina virtual de Key Vault recupera un certificado C: CN = "Malware de Mallory", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

La lista SAN del certificado A está totalmente incluida en la de C, por lo que A.renewal = C.thumbprint. La lista SAN de B tiene una intersección común con la de C, pero no está totalmente incluida en ella, por lo que B.renewal permanece vacío.

Cualquier intento de invocar a AcquireCredentialsHandle (Schannel) en este estado en el certificado A en realidad terminará enviando C a la parte remota. En el caso de Service Fabric, el subsistema de transporte de un clúster utiliza S-channel para la autenticación mutua, por lo que el comportamiento descrito anteriormente afecta directamente a la comunicación fundamental del clúster. Siguiendo con el ejemplo anterior, y suponiendo que A es el certificado del clúster, lo que sucede después depende de lo siguiente:

• Si la clave privada de C no se ha incluido en la ACL para la cuenta en la que se ejecuta Service Fabric, veremos que hay errores al adquirir la clave privada (SEC_E_UNKNOWN_CREDENTIALS o similar).
• Si la clave privada de C es accesible, veremos que los otros nodos devuelven errores de autorización (CertificateNotMatched, no autorizado, etc.).

En todo caso, se produce un error en el transporte y el clúster puede dejar de funcionar. Los síntomas varían. Para empeorar las cosas, la vinculación depende del orden de renovación, que viene determinado por el orden de la lista de certificados observados de la extensión de máquina virtual de Key Vault, la programación de renovación del almacén de claves o, incluso, por los errores transitorios que modificarían el orden de recuperación.

Para mitigar estos incidentes, se recomienda lo siguiente:

• No combine los nombres alternativos del firmante de certificados del almacén diferentes. Cada certificado del almacén debe servir para un propósito distinto, y su firmante y el SAN deberían reflejar eso de manera específica.

• Incluya el nombre común del firmante en la lista SAN (literalmente, CN=<subject common name>).

• Si no está seguro de cómo continuar, deshabilite la vinculación en la renovación de certificados que se aprovisionan con la extensión de máquina virtual de Key Vault.

  Nota

  Deshabilitar la vinculación es una propiedad de nivel superior de la extensión de máquina virtual de Key Vault y no se puede establecer para certificados observados individuales.

¿Por qué debo usar una identidad administrada asignada por el usuario? ¿Cuáles son las consecuencias de usarla?

Como se hizo evidente en los fragmentos de código JSON anteriores, se requiere una secuencia específica de las operaciones y actualizaciones para garantizar una correcta conversión y mantener la disponibilidad del clúster. Específicamente, el recurso del conjunto de escalado de máquinas virtuales declara y usa su identidad para recuperar los secretos en una única actualización (desde la perspectiva del usuario).

La extensión de máquina virtual de Service Fabric (que arranca el clúster) depende de la finalización de la extensión de máquina virtual de Key Vault, que a su vez depende de la recuperación correcta de los certificados observados.

La extensión de máquina virtual de Key Vault usa la identidad del conjunto de escalado de máquinas virtuales para acceder al almacén de claves, lo que significa que se debe haber actualizado la directiva de acceso en el almacén antes de la implementación del conjunto de escalado de máquinas virtuales.

Para disponer la creación de una identidad administrada o asignarla a otro recurso, el operador de implementación debe tener el rol necesario (ManagedIdentityOperator) en la suscripción o el grupo de recursos, además de los roles necesarios para administrar los demás recursos a los que se hace referencia en la plantilla.

Desde el punto de vista de la seguridad, recuerde que el conjunto de escalado de máquinas virtuales se considera un límite de seguridad con respecto a su identidad de Azure. Esto significa que cualquier aplicación hospedada en la máquina virtual podría, en principio, obtener un token de acceso que represente a la máquina virtual. Los tokens de acceso de la identidad administrada se obtienen del punto de conexión no autenticado de Instance Metadata Service. Si considera que la máquina virtual va a ser un entorno compartido o de varios inquilinos, es posible que este método de recuperación de certificados del clúster no sea el indicado. No obstante, es el único mecanismo de aprovisionamiento adecuado para la sustitución automática de certificados.

Solución de problemas y preguntas frecuentes

P: ¿Cómo puedo inscribirme mediante programación en un certificado administrado por Key Vault?

Averigüe el nombre del emisor en la documentación de Key Vault y reemplácelo en el script siguiente:

  $issuerName=<depends on your PKI of choice>
	$clusterVault="sftestcus"
	$clusterCertVaultName="sftstcncluster"
	$clusterCertCN="cus.cluster.sftstcn.system.servicefabric.azure-int"
	Set-AzKeyVaultCertificateIssuer -VaultName $clusterVault -Name $issuerName -IssuerProvider $issuerName
	$distinguishedName="CN=" + $clusterCertCN
	$policy = New-AzKeyVaultCertificatePolicy `
	    -IssuerName $issuerName `
	    -SubjectName $distinguishedName `
	    -SecretContentType 'application/x-pkcs12' `
	    -Ekus "1.3.6.1.5.5.7.3.1", "1.3.6.1.5.5.7.3.2" `
	    -ValidityInMonths 4 `
	    -KeyType 'RSA' `
	    -RenewAtPercentageLifetime 75        
	Add-AzKeyVaultCertificate -VaultName $clusterVault -Name $clusterCertVaultName -CertificatePolicy $policy
	
	# poll the result of the enrollment
	Get-AzKeyVaultCertificateOperation -VaultName $clusterVault -Name $clusterCertVaultName 

P: ¿Qué ocurre cuando un emisor no declarado o no especificado emite un certificado? ¿Dónde puedo obtener una lista exhaustiva de emisores activos de una PKI específica?

Si la declaración del certificado especifica huellas digitales de emisor, y el emisor directo del certificado no está incluido en la lista de emisores anclados, el certificado no se considerará válido, independientemente de si el cliente confía en su raíz o no. Por lo tanto, es fundamental asegurarse de que la lista de emisores esté actualizada. La introducción de un nuevo emisor es un evento poco habitual y se debe anunciar ampliamente antes de que empiece a emitir certificados.

En general, una PKI publica y mantiene una declaración de prácticas de certificación, de acuerdo con la RFC 7382 de IETF. Además de otra información, la declaración incluye todos los emisores activos. La recuperación de esta lista mediante programación puede diferir de una PKI a otra.

Para las PKI internas de Microsoft, asegúrese de consultar la documentación interna sobre los puntos de conexión y los SDK que se usan para recuperar los emisores autorizados. Es responsabilidad del propietario del clúster revisar esta lista periódicamente para asegurarse de que su definición de clúster incluya todos los emisores esperados.

P: ¿Se admiten varias PKI?

Sí. No puede declarar varias entradas de CN en el manifiesto de clúster con el mismo valor, pero puede enumerar los emisores de varias PKI correspondientes al mismo CN. No es una práctica recomendada, y las prácticas de transparencia de certificados pueden impedir que se emitan dichos certificados. Sin embargo, como medio para migrar de una PKI a otra, se considera un mecanismo aceptable.

P: ¿Qué ocurre si el certificado del clúster actual no está emitido por una CA o no tiene el firmante previsto?

Obtenga un certificado con el firmante previsto y agréguelo a la definición del clúster como secundario, por huella digital. Una vez que la actualización se haya completado correctamente, inicie otra actualización de la configuración del clúster para convertir la declaración del certificado al nombre común.