Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Rotación de la autoridad de certificación (CA) del clúster de EKS

En una infraestructura de clave pública (PKI), una autoridad de certificación (CA) es una entidad de confianza que emite y firma certificados digitales. Estos certificados establecen la identidad y permiten la comunicación cifrada entre sistemas mediante TLS (seguridad de la capa de transporte). Cuando un cliente se conecta a un servidor, el servidor presenta un certificado firmado por una CA. El cliente verifica el certificado del servidor con las CA en las que confía antes de permitir que la conexión continúe.

En Amazon Elastic Kubernetes Service (Amazon EKS), se crea una CA para cada clúster de EKS cuando se crea el clúster. Sigue el mismo modelo que Kubernetes ascendente: cada clúster de EKS tiene su propia CA que firma los certificados para el servidor de la API. Esto es lo que permite a los componentes del plano de control, los nodos de trabajo y los clientes autenticarse en el servidor de la API y establecer conexiones cifradas con el clúster de EKS.

Estas autoridades de certificación (CA) tienen un periodo de validez definido. La rotación de la CA es el proceso de reemplazar la autoridad de certificación del clúster de EKS antes de que caduque, lo que garantiza que el clúster permanezca operativo y accesible. Contamos con mecanismos de seguridad integrados que administran este proceso de forma automática. Si no inicia la rotación de la CA, agregaremos automáticamente una CA sucesora y la activaremos antes de que caduque la CA saliente, para asegurarnos de que el clúster siga disponible.

Durante la rotación de la CA, se agrega una CA sucesora al clúster de EKS. EKS distribuye automáticamente la CA sucesora a todos los componentes administrados de AWS (plano de control, instancias del modo automático de EKS y nodos de AWS Fargate). Usted es responsable de actualizar los nodos de trabajo que administra (que no son del modo automático de EKS ni Fargate) y los clientes externos (como los archivos kubeconfig y las canalizaciones de CI/CD) para que confíen en la CA sucesora antes de que se active. Una vez activada la CA sucesora, el clúster de EKS pasa a firmar certificados con la CA sucesora. A continuación, se retira la CA saliente.

La rotación de la CA es obligatoria para todos los clústeres de EKS, ya que las CA tienen un periodo de validez finito. El periodo de validez depende de cuándo se creó la CA del clúster. Para obtener más información, consulte la sección de preguntas frecuentes. Las medidas de seguridad de EKS garantizan que su propio clúster esté disponible durante todo el ciclo de vida de la rotación, pero una rotación correcta también depende de que actualice los nodos de trabajo que administra y los clientes externos para que mantengan la conectividad cuando se active la CA sucesora.

Las API, la experiencia de la consola, las notificaciones y las instrucciones paso a paso de las secciones siguientes están diseñadas para servirle de ayuda en este proceso. El ámbito completo de las responsabilidades se describe en la sección del modelo de responsabilidad compartida.

Cómo funciona la rotación de CA

La rotación de CA en Amazon EKS es un proceso de varias fases. Contamos con barreras de protección automáticas para preservar la disponibilidad del clúster de EKS durante todo el ciclo de vida de la rotación, independientemente de si usted actúa o no. Para lograr una rotación correcta, en la que todos los componentes mantengan la conectividad, es indispensable seguir los pasos de las siguientes secciones.

Fase 1: adición de una CA sucesora

Se agrega una CA sucesora al clúster de EKS. A partir de este punto, el clúster de EKS confía simultáneamente en la CA saliente y en la CA sucesora. La CA saliente continúa emitiendo los certificados. No se produce ninguna interrupción.

Puede incorporar una CA sucesora en cualquier momento mediante la AWS CLI, la API de EKS, la consola o la infraestructura como código (IaC), como AWS CloudFormation, siempre que el clúster esté en estado activo. Si no lo hace, agregaremos una automáticamente en su nombre.

La CA sucesora no se puede activar hasta que AWS complete la distribución a los componentes administrados de AWS en EKS (fase 2). Este es el momento adecuado para comenzar a identificar los nodos de trabajo y los clientes externos que deben actualizarse. Identificar todos los sistemas que se conectan al servidor de la API del clúster de EKS puede llevar tiempo, especialmente en entornos con varios equipos, canalizaciones de CI/CD y herramientas de supervisión. Comenzar este proceso con antelación le ofrece la mayor flexibilidad para coordinar las actualizaciones según su propio calendario.

Fase 2: distribución de la CA sucesora

Una vez incorporada la CA sucesora, AWS actualiza los componentes administrados del clúster de EKS (el plano de control, las instancias del modo automático de EKS y los nodos de AWS Fargate) para reconocer las dos CA y confiar en ellas. Puede hacer el seguimiento del progreso a través del estado de distribución de la CA. La CA sucesora no se puede activar hasta que se complete la distribución.

Una vez que hayamos completado la distribución de CA a los componentes administrados, usted es responsable de actualizar dos grupos: los nodos de trabajo que administra (que no sean del modo automático de EKS ni Fargate) y los clientes externos para que confíen en la CA sucesora. Esto garantiza que continuarán conectándose al servidor de la API después de que se active la CA sucesora. Si algún componente no se actualiza antes de la activación de la CA sucesora, la reversión de la CA está disponible para restablecer la conectividad mientras se completan las actualizaciones restantes.

Fase 3: activación de la CA sucesora

Cuando hayamos completado la distribución de la CA sucesora a todos los componentes administrados de AWS en EKS, se podrá activar la CA sucesora. Le recomendamos activar la CA sucesora según su propio calendario. Tómese el tiempo suficiente para detectar y actualizar los nodos de trabajo que administra y los clientes externos para confiar en la CA sucesora. Después de la activación de la CA sucesora, el clúster de EKS emite certificados firmados por la CA sucesora. La CA saliente continúa siendo de confianza, pero ya no se utiliza para firmar. Hay disponible un plazo de reversión durante un periodo limitado después de la activación, que le permite volver a la CA saliente si es necesario. La reversión se trata en detalle en una sección posterior.

Puede activar la CA sucesora cuando sepa con seguridad que se hayan actualizado los nodos de trabajo que administra y los clientes. Si no lo hace, activaremos la CA sucesora automáticamente según se acerque la fecha límite de caducidad.

Periodo de doble confianza

El tiempo que transcurre entre la incorporación de una CA sucesora (fase 1) y la retirada de la CA saliente se denomina periodo de doble confianza. Durante este tiempo, el clúster de EKS confía en las dos CA simultáneamente. Esto es lo que hace que la rotación no interrumpa los procesos: los componentes se pueden actualizar de forma incremental porque el clúster de EKS acepta certificados firmados por cualquiera de las CA.

El periodo de doble confianza le da tiempo para identificar y actualizar todos los nodos de trabajo que administra y los clientes externos sin necesidad de coordinar todos los cambios simultáneamente.

Es importante entender cómo la activación de la CA sucesora afecta a la conectividad. Cuando un cliente se conecta al servidor de la API, comprueba que una CA en la que confía haya firmado el certificado del servidor para verificar la identidad del servidor.

Una vez activada la CA sucesora, el servidor de la API presenta su certificado firmado por la CA sucesora. Los clientes que hayan actualizado el paquete de confianza para incluir la CA sucesora lo verificarán correctamente y se conectarán de forma normal. Los clientes que no hayan actualizado el paquete de confianza no reconocerán el certificado del servidor y no podrán establecer una conexión.

En el siguiente diagrama, se muestra el flujo de conexión de TLS después de la activación de la CA sucesora.

Por eso es importante actualizar los nodos de trabajo y los clientes externos antes de activar la CA sucesora: necesitan la CA sucesora en el paquete de confianza para verificar la identidad del servidor de la API y conectarse. El periodo de doble confianza y la reversión de la CA le proporcionan tiempo y una red de seguridad para completar este proceso.

Modelo de responsabilidad compartida

La rotación de la CA en Amazon EKS sigue el mismo modelo de responsabilidad compartida que se aplica en AWS. AWS es responsable de la seguridad y la disponibilidad de la infraestructura en la nube, mientras que usted es responsable de la seguridad y la configuración de las cargas de trabajo que contiene. Para obtener más información sobre cómo se aplica la responsabilidad compartida a Amazon EKS, consulte las prácticas recomendadas de seguridad de EKS.

En el contexto de la rotación de CA, esto significa lo siguiente:

La responsabilidad de AWS incluye:

Su responsabilidad incluye:

No podemos llevar a cabo estas acciones en su nombre. Los clientes externos existen fuera del límite operativo de AWS. Los nodos de trabajo que no están administrados por el modo automático de EKS ni Fargate tienen su configuración de confianza de CA establecida en el momento del lanzamiento o mediante procesos de arranque que solo usted controla. Es coherente con el funcionamiento de la confianza de TLS: el cliente tiene su propio almacén de confianza y solo el administrador del cliente puede actualizarlo.

En las secciones siguientes, se amplía cada aspecto: qué hace AWS por usted y qué debe hacer usted, además de una guía paso a paso sobre cómo hacerlo.

Qué hace AWS por usted

AWS administra lo siguiente durante todo el ciclo de vida de la rotación de la CA para el clúster de EKS:

Creación automática de la CA

Si no agrega una CA sucesora en su propio calendario, agregaremos una automáticamente según se acerque la fecha de caducidad de la CA saliente del clúster de EKS. Esto garantiza que el proceso de rotación comience con tiempo suficiente para que pueda encontrar y actualizar los clientes antes de la fecha límite de caducidad.

Actualizaciones del plano de control

Actualizamos automáticamente el plano de control del clúster de EKS para que confíe en la CA sucesora. Después de la activación de la CA sucesora, el plano de control emite certificados firmados por la CA sucesora. No es necesario que lleve a cabo ninguna acción en el plano de control.

Actualizaciones del modo automático de EKS y Fargate

Actualizamos automáticamente los nodos del modo automático de EKS y los pods de Fargate para que confíen en la CA sucesora. Administramos completamente estos componentes y no es necesario que lleve a cabo ninguna acción durante la rotación de CA.

Actualizaciones de capacidades de EKS

Actualizamos automáticamente las capacidades de EKS (Controladores de AWS para Kubernetes [ACK], Argo CD y kro [Orquestador de recursos de Kube]) para que confíen en la CA sucesora. Estos recursos administrados se comunican con el servidor de la API del clúster y se actualizan como parte del proceso de distribución de CA. No es necesario que lleve a cabo ninguna acción en relación con los recursos administrados de las capacidades de EKS. Para obtener más información, consulte Capacidades de EKS.

Seguimiento del estado de la distribución

A medida que actualizamos los componentes administrados del clúster de EKS, puede supervisar el progreso del estado de distribución de la CA. Esto le indica si hemos completado nuestra parte de la rotación. La CA sucesora no se puede activar hasta que se complete la distribución.

Barreras de protección integradas

Contamos con barreras de protección integradas para proteger el clúster de EKS durante la rotación:

Estas barreras de protección garantizan que la disponibilidad del clúster de EKS se mantenga durante el ciclo de vida de la rotación, independientemente de si usted actúa o no.

Notificaciones

Le enviaremos notificaciones en cada fase del ciclo de vida de la rotación de la CA. Las notificaciones se envían a través de AWS Health, Información de clústeres y correo electrónico. Cada notificación le indica qué ha ocurrido, qué medidas (si las hubiera) debe tomar y en qué lugar del calendario de rotación se encuentra el clúster de EKS.

También puede configurar sus propias notificaciones mediante Amazon EventBridge para integrar los eventos de rotación de la CA en los flujos de trabajo de supervisión y alertas existentes.

Qué debe hacer (y por qué)

Una rotación de la CA correcta requiere que actualice los componentes a los que AWS no puede acceder en su nombre. Se dividen en dos categorías:

Clientes externos

Cualquier sistema que se conecte al servidor de la API del clúster de EKS desde fuera del clúster. Esto incluye estaciones de trabajo para desarrolladores, canalizaciones de CI/CD (Jenkins, GitHub Actions, GitLab, Argo CD), herramientas de supervisión y observabilidad, scripts de automatización y cualquier aplicación que use kubeconfig para comunicarse con el servidor de la API.

Cada uno de estos sistemas mantiene su propia configuración de confianza. Cuando se activa la CA sucesora, el servidor de la API presenta certificados firmados por la CA sucesora. La actualización de estos clientes para que confíen en la CA sucesora antes de activarla garantiza que mantengan la conectividad. Si se omite un cliente, la reversión de la CA puede restablecer el acceso mientras se completa la actualización.

Nodos de trabajo (que no sean del modo automático de EKS ni Fargate)

Los nodos de trabajo que no están administrados por el modo automático de EKS ni Fargate tienen su configuración de confianza de la CA establecida en el momento del lanzamiento o a través del proceso de arranque de kubelet. Estos nodos deben actualizarse para que confíen en la CA sucesora. La acción que se debe llevar a cabo depende del tipo de nodo de trabajo:

Grupos de nodos administrados

Actualice la versión del grupo de nodos, lo que desencadenará una sustitución progresiva de los nodos. Los nuevos nodos arrancan automáticamente con la configuración de confianza de la CA actualizada.

Nodos controlados por Karpenter

Si la detección de desviaciones está habilitada, Karpenter recorrerá los nodos dentro del plazo de desviación configurado y los nuevos nodos adoptarán la CA sucesora sin necesidad de llevar a cabo ninguna acción manual. Si la detección de desviaciones está deshabilitada o configurada en un plazo largo, trate estos nodos como nodos autoadministrados.

Nodos autoadministrados

Sustituya los nodos para que arranquen con la configuración de confianza de la CA actualizada. Por lo general, esto implica actualizar la plantilla de lanzamiento con los datos de la CA actualizados y desencadenar una sustitución progresiva a través del grupo de escalado automático.

Nodos híbridos

Actualice la configuración de confianza en cada nodo híbrido para incluir la CA sucesora. El proceso específico depende de cómo se hayan arrancado los nodos híbridos y de cómo se administre su configuración de confianza.

Puede identificar qué tipos de nodos de trabajo se están ejecutando en el clúster de EKS mediante Información de clústeres. En una sección posterior se proporcionan instrucciones detalladas paso a paso para actualizar cada tipo.

Proporcionamos la reversión de la CA como red de seguridad en caso de que se omita algún nodo de trabajo. Sin embargo, la actualización de todos los nodos de trabajo antes de la activación de la CA sucesora evita por completo las interrupciones de la conectividad. Los nodos que no se actualicen antes de que se active la CA sucesora perderán la conectividad con el servidor de la API del clúster de EKS hasta que se sustituyan o se revierta la CA.

¿Por qué solo usted puede hacer esto?

Los clientes externos existen fuera del límite operativo de AWS. Una canalización de CI/CD que se ejecuta en la red corporativa, el portátil de un desarrollador o una herramienta de supervisión alojada en las instalaciones: AWS no tiene ningún mecanismo para acceder a estos sistemas y actualizar la configuración de confianza.

La configuración de confianza de los nodos de trabajo que no sean del modo automático de EKS se controla mediante plantillas de lanzamiento, scripts de datos de usuario o procesos de arranque propios. Para actualizarlos, es necesario sustituir los nodos o modificar su configuración, acciones que se llevan a cabo dentro de la infraestructura.

Es una limitación del modelo de confianza de TLS que utiliza Kubernetes actualmente. No existe ningún mecanismo de protocolo para que el servidor de la API consulte si un cliente ha actualizado su paquete de confianza. El servidor solo puede presentar su certificado cuando un cliente se conecta. Si el cliente confía en la CA que lo firmó, la conexión se efectuará correctamente. Si no, se producirá un error. No existe ninguna ruta de verificación previa a la activación que permita a AWS confirmar que los componentes estén listos.

Cuándo comenzar

Comience a identificar los clientes externos lo antes posible. Esta es la parte que más tiempo lleva de la rotación de la CA, especialmente en entornos con varios equipos que implementan cargas de trabajo de forma independiente en el clúster de EKS. Cuanto antes comience a detectar clientes, más tiempo tendrá para coordinar las actualizaciones entre los equipos sin presión.

En las secciones siguientes, se proporciona una guía detallada sobre cómo actualizar cada tipo de cliente y nodo de trabajo.

Requisitos previos

Antes de iniciar la rotación de la CA, confirme lo siguiente:

No se requieren permisos de IAM adicionales a los necesarios para administrar el clúster de EKS. Si puede llamar a las API de EKS para el clúster de EKS actualmente, puede efectuar la rotación de la CA.

Introducción

Puede llevar a cabo la rotación de la CA mediante la AWS CLI o la consola de Amazon EKS. Asegúrese de que esté ejecutando la versión 2.x o posterior de la AWS CLI (aws --version para comprobarlo).

Uso de la CLI de AWS

En el siguiente tutorial, se describe el proceso de rotación de la CA de principio a fin mediante la AWS CLI y las API de EKS.

Paso 1: comprobación de la CA activa

Vea la autoridad de certificación activa en el clúster de EKS.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Resultado previsto:

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

Muestra la CA que se creó al crear el clúster de EKS. Se está usando actualmente (firma de certificados) y su distribución está completa (todos los componentes administrados de AWS en EKS confían en ella).

Paso 2: consulta de los detalles y la fecha de caducidad de la CA

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

Resultado previsto:

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

El bloque validity muestra cuándo se creó la CA (notBefore y cuándo caduca (notAfter). rollbackAvailable indica si se puede revertir a una CA anterior después de activar la CA sucesora. En el caso de la CA inicial creada con el clúster de EKS, será false porque no hay ninguna CA anterior a la que revertirla.

Paso 3: adición de una CA sucesora

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

Agrega una CA sucesora al clúster de EKS. La respuesta incluye una updateId que puede utilizar para hacer un seguimiento del progreso.

Paso 4: seguimiento de la actualización

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

Espere hasta que se muestre el estado de la actualización Successful.

Paso 5: verificación del estado de la distribución

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Ahora debería ver dos CA. La CA sucesora tendrá signingStatus: NOT_USED y distributionStatus pasará de IN_PROGRESS a COMPLETE después de que AWS haya actualizado todos los componentes administrados en el clúster de EKS.

No continúe hasta que el estado de distribución de la CA sucesora sea COMPLETE.

Paso 6: actualización de kubeconfig

aws eks update-kubeconfig --name my-cluster --region us-west-2

Esto actualiza su kubeconfig local para que confíe en las dos CA. Después de esto, los comandos de kubectl continuarán funcionando una vez que se active la CA sucesora.

Paso 7: actualización de los nodos de trabajo que administra y los clientes externos

Esto se explica en detalle en la siguiente sección. Una vez que todos los nodos de trabajo que administra y los clientes externos se hayan actualizado para que confíen en la CA sucesora, continúe con la activación.

Paso 8: activación de la CA sucesora

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

Después de la activación de la CA sucesora, el clúster de EKS emite certificados firmados por la CA sucesora. Verifique la conectividad para confirmar que todos los componentes funcionen según lo previsto.

Utilizar la consola de Amazon EKS

La consola de Amazon EKS ofrece una experiencia guiada para la rotación de la CA. Puede ver el estado de la CA, agregar una CA sucesora, supervisar el progreso de la distribución y activar la CA sucesora directamente desde la consola.

En la siguiente imagen, se muestra la vista de detalles de la autoridad de certificación en la consola de Amazon EKS durante una rotación activa. Tanto la CA activa como la CA sucesora se muestran con su estado de firma, fecha de caducidad y días hasta la fecha de caducidad.

En la imagen siguiente, se muestra la vista del progreso de la rotación en la consola de Amazon EKS. Cada paso del proceso de rotación se muestra con su estado actual, lo que incluye la adición, la distribución, la actualización de los nodos de trabajo y los clientes externos, la activación y la eliminación de la CA saliente.

Actualización de los clientes de Kubernetes

Una vez que se haya agregado la CA sucesora y AWS haya completado la distribución a los componentes administrados en el clúster de EKS (distributionStatus: COMPLETE), tendrá que actualizar sus propios componentes para que confíen en la CA sucesora. En este contexto, un “cliente” es cualquier sistema que se conecte al servidor de la API del clúster de EKS. Esto incluye la configuración local de kubectl, las canalizaciones de CI/CD, las herramientas de supervisión, los scripts de automatización y los nodos de trabajo.

Los datos de CA actualizados del clúster de EKS (que ahora contienen las CA actuales y las sucesoras) se pueden recuperar de la siguiente manera:

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

Utilice este valor para actualizar la configuración de confianza de cada tipo de cliente en las siguientes subsecciones.

Kubeconfig (estaciones de trabajo para desarrolladores, canalizaciones de CI/CD, automatización)

Ejecute lo siguiente para actualizar la configuración de kubeconfig local:

aws eks update-kubeconfig --name my-cluster --region us-west-2

Esto recupera automáticamente los datos de la CA más recientes y actualiza su kubeconfig. Cualquier sistema que utilice este kubeconfig confiará en las dos CA.

Para las canalizaciones de CI/CD y la automatización que generan su propio kubeconfig (por ejemplo, con las API de EKS directamente o al almacenar kubeconfig como un secreto), actualice el campo certificate-authority-data con el valor recuperado de describe-cluster.

Grupos de nodos administrados

Actualice la versión del grupo de nodos para desencadenar una sustitución progresiva de los nodos:

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

Los nuevos nodos arrancan automáticamente con los datos de la CA actualizados. La sustitución progresiva garantiza que los nodos se sustituyan individualmente sin interrumpir las cargas de trabajo en ejecución.

Si administra los grupos de nodos a través de Terraform o CloudFormation, la rotación de la CA no crea ninguna desviación en el estado de IaC. El ciclo de vida de la CA se administra mediante API de EKS dedicadas que son independientes de la configuración de recursos del clúster. Para obtener más información sobre cómo la rotación de la CA interactúa con la infraestructura como código, consulte la sección Infraestructura como código.

Plantilla de lanzamiento personalizada con una AMI personalizada

Si el grupo de nodos se implementa con una AMI personalizada, AWS no combina los datos del usuario. Es responsable de proporcionar la configuración de arranque correcta, incluido el paquete de confianza de la CA actualizado. La rotación de la CA no actualiza los datos de usuario y un nodo sin la CA sucesora no puede unirse al clúster.

Verificación de que los nodos se estén ejecutando en la plantilla de lanzamiento actualizada

Antes de continuar la activación, confirme que todos los nodos del grupo de nodos administrado utilicen la versión más reciente de la plantilla de lanzamiento. Esta versión debe contener el paquete de confianza de la CA actualizado.

Nodos controlados por Karpenter

Si la detección de desviaciones está habilitada en el grupo de nodos de Karpenter, Karpenter detectará automáticamente si los nodos están funcionando con datos de la CA desactualizados y los sustituirá dentro del intervalo de interrupción configurado. Los nuevos nodos recogerán la CA sucesora sin necesidad de efectuar ninguna acción manual.

Compruebe que la detección de desviaciones esté habilitada en la configuración de NodePool:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

Si disruption está configurado con una política de consolidación, la detección de desviaciones está activa de forma predeterminada. Karpenter sustituirá los nodos que se hayan desviado del estado deseado, lo que incluye los cambios en los datos de la CA.

Si la detección de desviaciones está habilitada, compruebe que el presupuesto de interrupciones permita sustituir todos los nodos controlados por Karpenter antes de la fecha de activación de la CA sucesora. Si el presupuesto es demasiado restrictivo (por ejemplo, un periodo de mantenimiento reducido con un porcentaje de sustitución bajo), es posible que no todos los nodos se sustituyan a tiempo.

Si la detección de desviaciones está deshabilitada o los presupuestos para interrupciones restringen las sustituciones a un plazo que supere el plazo de rotación, puede acordonar y drenar los nodos para activar manualmente su sustitución:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter proporcionará un nodo de sustitución que arrancará con los datos de la CA actualizados.

Nodos autoadministrados

En el caso de los nodos autoadministrados, es necesario actualizar los datos de la CA de la plantilla de lanzamiento o del script de datos de usuario que utilicen los nodos durante el arranque:

Los nodos nuevos se iniciarán con los datos de la CA actualizados y confiarán tanto en las CA actuales como en las sucesoras.

Pods de AWS Fargate (tipo de lanzamiento de Fargate de EKS)

Los pods de AWS Fargate del clúster de EKS funcionan de forma diferente a otros modos de lanzamiento del plano de datos de EKS (grupos de nodos administrados, nodos autoadministrados, nodos controlados por Karpenter).

Cuando un pod se conecta al servidor de la API, ocurren dos cosas: el pod se autentica mediante el token de la cuenta de servicio (lo que demuestra su identidad ante el servidor de la API) y el pod verifica la identidad del servidor de la API al comprobar que una CA en la que confía firmó el certificado del servidor. Los datos de la CA almacenados en el entorno del pod son los que hacen posible esta verificación. Si el servidor de la API comienza a presentar certificados firmados por una CA sucesora en la que el pod no confía, este rechazará la conexión.

En otros modos de lanzamiento del plano de datos de EKS (grupos de nodos administrados, nodos autoadministrados, nodos controlados por Karpenter), los datos de la CA residen en el nodo. Cuando se sustituye el nodo, el nuevo nodo se inicia con los datos de la CA actualizados. Los pods programados en ese nuevo nodo reciben los datos de la CA actualizados, lo que les permite verificar el servidor de la API independientemente de la CA que haya firmado su certificado.

En Fargate, cada pod se ejecuta en su propio entorno de computación dedicado con su propio proceso de kubelet. Este kubelet se inicia con los datos de la CA en el momento en que se crea el pod. No hay ningún nodo compartido en la parte inferior y no se tiene acceso directo a la computación subyacente.

No se requiere ninguna acción por parte del cliente para los nodos de AWS Fargate en EKS durante la rotación de la CA. AWS recicla de forma natural los pods en los nodos de Fargate mediante su proceso de aplicación de parches. Después de agregar una CA sucesora, los pods de Fargate preexistentes se reciclan como parte de este proceso. Confiarán en la CA sucesora sin que tenga que llevar a cabo ninguna acción. Como AWS agrega la CA sucesora mucho antes de cualquier calendario de activación de la CA iniciado por AWS en EKS, los pods de Fargate se habrán reciclado y confiarán en la CA sucesora cuando AWS la active. Hay una barrera de protección integrada que impide la activación de la CA sucesora hasta que los pods de Fargate hayan terminado de reciclarse.

Esto significa que las dos opciones de planos de datos administrados (modo automático de EKS y Fargate) para un clúster de EKS tienen la misma experiencia de usuario para la rotación de CA: los nodos de trabajo no requieren ninguna acción por parte del cliente. Continúa siendo responsable de actualizar los clientes externos que se conecten al servidor de la API.

Se trata de un caso extremo. Dado el calendario de rotación (la CA sucesora se agrega años antes de su caducidad), el ciclo natural de aplicación de parches se completará mucho antes de la activación de la CA sucesora en la gran mayoría de los casos. La barrera de protección existe como medida preventiva para el improbable caso de que un cliente intente llevar a cabo la activación antes de tiempo.

Clientes externos (herramientas de supervisión, integraciones de terceros)

Cualquier aplicación o herramienta que se conecte al servidor de la API del clúster de EKS mediante una configuración de kubeconfig o de certificado de confianza debe actualizarse con los datos de CA actualizados. Esto incluye:

Para cada uno de ellos, sustituya los datos de la CA almacenados por el valor actualizado de describe-cluster.

Cómo verificar que un cliente se haya actualizado

Después de actualizar un cliente, confirme que aún pueda comunicarse con el servidor de la API:

kubectl get nodes

Si el comando se ejecuta correctamente, kubeconfig confía en los datos de la CA activos. Después de activar la CA sucesora, ejecute el mismo comando para confirmar la continuidad de la conectividad.

Infraestructura como código

Puede llevar a cabo la rotación de CA junto con la infraestructura como código (IaC) actual sin crear desviaciones ni requerir cambios en las configuraciones de IaC.

Por qué la rotación de la CA no afecta al estado de IaC

El ciclo de vida de la CA se administra mediante API de EKS dedicadas (create-certificate-authority, activate-certificate-authority, delete-certificate-authority) que son completamente independientes de la configuración de recursos del clúster de EKS. Independientemente de si inicia la rotación de la CA o la inicia AWS automáticamente, no se modifica ninguna propiedad rastreada por las herramientas de IaC en el recurso del clúster de EKS.

Esto significa:

El campo certificateAuthority.data devuelto por describe-cluster es un resultado de solo lectura. Refleja el paquete de confianza combinado actual (las dos CA durante el periodo de doble confianza), pero no es una propiedad configurable. Las herramientas de IaC no lo rastrean como algo que deba conciliarse.

Los campos de atribución (createdBy, activatedBy) de cada registro de la CA le permiten distinguir entre las operaciones que inició y las que AWS inició automáticamente, lo que facilita los flujos de trabajo de auditoría y administración de cambios.

Uso de CloudFormation con rotación de la CA

La rotación de la CA se puede desencadenar a través de CloudFormation mediante una propiedad WriteOnly del recurso AWS::EKS::Cluster. Esta propiedad desencadena la activación, pero no se almacena en el estado de la pila, por lo que las actualizaciones posteriores de la pila sin ella no intentan revertirse ni desactivarse.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

Esta primera actualización de la pila agrega una CA sucesora al clúster. Espere a que el estado de distribución de la CA sucesora llegue a COMPLETE antes de continuar.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

Esta segunda actualización de la pila desencadena la activación de la CA sucesora. Como ActiveCertificateAuthorityId es una propiedad WriteOnly, no se devuelve al leerla y CloudFormation no detectará desviaciones si la CA activa cambia fuera de CloudFormation (por ejemplo, mediante la activación automática por parte de AWS).

Importante: La integración de CloudFormation con la rotación de la CA sigue un patrón diferente al de los recursos típicos de CloudFormation. Una autoridad de certificación en EKS no es un recurso independiente con su propio ARN. Existe como parte del ciclo de vida de los certificados del clúster y se autoriza a través del propio clúster, de forma similar a como se autoriza una política de rol de IAM a través del rol principal (AWS::IAM::RolePolicy) o una asociación de EIP a través de la instancia (AWS::EC2::EIPAssociation). Los clientes que administran la rotación de la CA a través de CloudFormation deben conocer esta distinción.

Grupos de nodos administrados e IaC

Actualizar la versión del grupo de nodos para actualizar los nodos con la configuración de confianza de la CA actualizada es una acción operativa. Los nodos nuevos arrancan automáticamente con los datos de confianza de la CA activos del clúster. Si las plantillas de IaC no codifican los datos de la CA en las plantillas de lanzamiento o los datos del usuario, no es necesario hacer cambios en las plantillas.

Reversión de la CA

Después de activar una CA sucesora, puede volver a la CA anterior si detecta problemas de conectividad con los nodos de trabajo que administra (que no sean del modo automático de EKS ni Fargate) o con los clientes externos. La reversión reactiva la CA anterior como autoridad de firma del clúster de EKS.

Cuándo está disponible la reversión de la CA

La reversión de la CA está disponible después de la activación de la CA siempre que:

Puede comprobar si la reversión de la CA está disponible en cualquier momento con el campo rollbackAvailable devuelto por describe-certificate-authority:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

Cuándo no está disponible la reversión de la CA

La reversión de la CA no está disponible después de la activación automática final. Si AWS activa la CA sucesora por última vez (45 días antes del vencimiento de la CA), la rotación debe continuar. La activación automática final solo se produce si la primera activación automática se anuló previamente. Existe como barrera de protección de último recurso para garantizar que el clúster de EKS no llegue a la caducidad de la CA sin contar con una CA válida.

Cómo se revierte

Para revertirla, vuelva a activar la CA anterior:

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

¿Qué ocurre durante la reversión de la CA?

Cuándo se debe considerar la reversión de la CA

La reversión de la CA es un mecanismo de seguridad para situaciones en las que la activación de la CA sucesora revela un problema de conectividad que no se detectó de antemano:

Tras la reversión, se retiene todo el periodo de doble confianza para identificar y solucionar el problema antes de volver a activar la CA sucesora.

Recuperación sin reversión de la CA

Si activa la CA sucesora antes de actualizar los grupos de nodos administrados y el plazo de reversión de la CA ya no está disponible (por ejemplo, después de la fecha límite de la activación automática final), puede recuperarse con una actualización progresiva en los grupos de nodos afectados. Sin embargo, se producirá un error en el intento inicial de actualización progresiva porque los nodos desconectados no pueden recibir los comandos de expulsión de los pods desde el servidor de la API.

Pasos de recuperación

Consideraciones y limitaciones

Disponibilidad en las regiones

La rotación de la CA está disponible en todas las regiones comerciales de AWS en las que se admita Amazon EKS.

Máximo dos CA

Un clúster de EKS puede tener como máximo dos CA en cualquier momento: la CA activa y una sucesora. No se puede agregar una segunda CA sucesora hasta que se complete la rotación anterior.

Sin revocación de certificados

La rotación de la CA no admite la revocación de certificados individuales. Es coherente con Kubernetes ascendente, que no implementa la revocación de certificados (CRL u OCSP). La rotación reemplaza a toda la CA, lo que, naturalmente, invalida todos los certificados firmados por la CA saliente una vez eliminada del paquete de confianza.

Las CA agregadas por AWS no se pueden eliminar

Si AWS agrega automáticamente una CA sucesora, no podrá eliminarla. Esta protección garantiza que el proceso de rotación no pueda interrumpirse por una eliminación accidental. Las CA agregadas por el cliente se pueden eliminar siempre que no sean la CA firmante activa.

Periodo de validez de la CA

La CA original creada con el clúster tiene un periodo de validez de 10 años. Las CA sucesoras creadas mediante el proceso de rotación tienen periodos de validez de 5 años. Todas las CA futuras del clúster tendrán un periodo de validez de 5 años. Compruebe la fecha de caducidad de la CA con describe-certificate-authority.

Tamaño de los datos del usuario de EC2 durante la doble confianza

Durante el periodo de doble confianza, el paquete de confianza del clúster aumenta de tamaño porque contiene dos certificados de CA (aproximadamente 2,8 KB juntos o aproximadamente 1,9 KB con compresión gzip). En el caso de los nodos de trabajo en los que se proporcionan datos de usuario personalizados en las plantillas de lanzamiento de EC2, verifique que el tamaño total de los datos de usuario no supere el límite de 16 KB de datos de usuario de EC2. Si los datos del usuario actuales están cerca de este límite, la adición de una segunda CA podría provocar un error en la creación de la plantilla de lanzamiento e impedir el aprovisionamiento de nuevos nodos. Considere la posibilidad de comprimir el contenido de los datos de usuario con gzip para reducir el tamaño.

Actualizaciones de la versión durante la rotación de la CA

Las actualizaciones de la versión del clúster de EKS y la rotación de la CA son operaciones independientes. Sin embargo, no puede hacer las dos tareas simultáneamente. Si hay una operación de rotación de la CA en curso, se rechazará la actualización de la versión hasta que se complete la operación de la CA y viceversa.

Traiga su propia CA (BYOCA)

Actualmente, no se admite el uso de su AWS Private CA privada para respaldar los certificados del clúster de EKS.

Preguntas frecuentes

¿Cómo comienzo a utilizar la rotación de la CA?

Para comenzar, ejecute aws eks list-certificate-authorities --cluster-name my-cluster para ver la CA activa y la fecha de caducidad. Si lo tiene todo listo para iniciar la rotación, ejecute aws eks create-certificate-authority --cluster-name my-cluster para agregar una CA sucesora. En la sección Introducción, se trata todo el proceso paso a paso. También puede llevar a cabo la rotación de la CA mediante la consola de Amazon EKS.

¿Hay algún costo asociado a la rotación de la CA?

No. La rotación de la CA está disponible sin costo adicional para todos los clústeres de EKS.

¿Qué ocurre si no cambio mi CA antes de que caduque?

Contamos con barreras de protección automáticas que impiden que el clúster de EKS llegue a la fecha de caducidad de la CA sin contar con una CA válida. Si no inicia la rotación de la CA, agregaremos y activaremos automáticamente una CA sucesora antes de la fecha de caducidad, para asegurarnos de que el clúster siga disponible.

Sin embargo, una rotación correcta también requiere que actualice los nodos de trabajo que administra (que no sean del modo automático de EKS ni Fargate) y los clientes externos para que confíen en la CA sucesora. Si estos componentes no se actualizan antes de que se active la CA sucesora, perderán la conectividad con el servidor de la API.

En Kubernetes, si una CA no se rota antes de que caduque, todos los certificados firmados por esa CA dejarán de ser válidos. Ningún cliente podrá acceder al servidor de la API y el clúster dejará de estar disponible.

¿De cuánto tiempo dispongo para completar la rotación de la CA?

El tiempo total necesario para completar la rotación de la CA depende tanto de las barreras de protección automatizadas de AWS como del propio proceso de actualización.

AWS proporciona plazos definitivos para la que administra. Se agrega una CA sucesora aproximadamente 2 años antes de que caduque la CA saliente. Si no activa la CA sucesora, la activaremos automáticamente aproximadamente 6 meses antes de que caduque. Si efectúa una reversión después de la activación automática, llevaremos a cabo una última activación automática 45 días antes de que caduque. Estas barreras de protección garantizan que el clúster de EKS permanezca disponible independientemente de si usted actúa o no.

Una rotación de la CA correcta también depende de que actualice los nodos de trabajo que administra (que no sean del modo automático de EKS ni Fargate) y los clientes externos para que confíen en la CA sucesora antes de activarla. El tiempo que dure depende de la configuración del nodo de trabajo del plano de datos, la huella de los clientes externos y el tiempo que tarde en detectar y actualizar estos componentes.

¿La rotación de la CA provoca un tiempo de inactividad en mi clúster?

No. El clúster de EKS permanece disponible durante todo el ciclo de vida de la rotación de la CA. El plano de control continúa atendiendo las solicitudes en todas las fases. Durante el periodo de doble confianza, se confía simultáneamente en la CA saliente y la sucesora, lo que permite actualizar los componentes de forma incremental sin interrumpir las operaciones del clúster. Si ha revertido a la CA anterior porque ha detectado problemas relacionados con el cliente, AWS lleva a cabo una última renovación aproximadamente 45 días antes de la fecha de caducidad de la CA saliente como barrera de protección.

Es importante distinguir entre el clúster de EKS (plano de control) y los componentes del plano de datos. El plano de control está completamente administrado por AWS y está disponible durante toda la rotación.

Para el modo automático de EKS y Fargate, AWS actualiza los nodos de trabajo automáticamente. No hay riesgo de pérdida de conectividad para los nodos de trabajo en estos modos de lanzamiento del plano de datos. Continúa siendo responsable de actualizar los clientes externos que se conecten al servidor de la API.

En el caso de los grupos de nodos administrados, los nodos autoadministrados, las instancias controladas por Karpenter (sin activar la detección de desviaciones) y los nodos híbridos, usted es responsable de sustituir o actualizar esos nodos antes de activar la CA sucesora. Si no se sustituyen, esos nodos perderán la conectividad con el plano de control una vez que se active la CA sucesora, aunque el propio plano de control continúe funcionando a pleno rendimiento.

¿Se interrumpirán mis cargas de trabajo durante la rotación de la CA?

La rotación de la CA no interrumpe las cargas de trabajo en ejecución (pods). Los pods se comunican entre sí a través de la red de clústeres, a la que no afecta el cambio de la CA. La CA se utiliza para la comunicación entre los componentes y el servidor de la API, no para el tráfico de pod a pod.

Si es necesario sustituir los nodos de trabajo como parte de la actualización para que puedan confiar en la CA sucesora (por ejemplo, si los grupos de nodos administrados llevan a cabo una actualización continua o si Karpenter sustituye los nodos desviados), los pods de esos nodos se reprogramarán como parte del proceso normal de sustitución de nodos. Este es el comportamiento estándar de Kubernetes durante la sustitución de nodos, no se trata de ningún efecto secundario de la rotación de la CA. Asegúrese de configurar los presupuestos de interrupción de pods (PDB) para las cargas de trabajo críticas a fin de controlar la forma en que se expulsan los pods durante la sustitución de nodos.

¿Cuándo caducará la CA de mi clúster?

Puede comprobar cuándo caduca la CA de su clúster mediante la AWS CLI, las API de EKS o la consola de Amazon EKS. Por ejemplo, puede ejecutar lo siguiente:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

Para encontrar el ID de la CA, ejecute aws eks list-certificate-authorities --cluster-name my-cluster.

¿Cuál es el periodo de validez de la CA de mi clúster?

La CA original creada con el clúster tiene un periodo de validez de 10 años. Las CA sucesoras creadas mediante el proceso de rotación tienen periodos de validez de 5 años. Todas las CA futuras del clúster tendrán un periodo de validez de 5 años. Puede comprobar la fecha de caducidad de la CA con describe-certificate-authority.

¿Puedo iniciar una rotación de la CA antes de que AWS lo haga automáticamente?

Sí. Puede agregar una CA sucesora en cualquier momento con aws eks create-certificate-authority --cluster-name my-cluster. No es necesario esperar a que AWS inicie la rotación. Comenzar pronto le da más tiempo para identificar y actualizar los nodos de trabajo y clientes externos según su propio calendario.

¿Puedo revertirla después de activar una CA sucesora?

Sí, la reversión de la CA está disponible después de activar la CA sucesora, siempre y cuando el plazo de reversión no haya caducado. La reversión de la CA reactiva la CA anterior como autoridad firmante. No está disponible después de la activación automática final (45 días antes de la fecha de caducidad de la CA). Puede comprobar el campo rollbackAvailable de la CA con describe-certificate-authority. Para obtener más información, consulte la sección Reversión de la CA.

¿Cómo sé cuándo es seguro activar la CA sucesora?

Es seguro activar la CA sucesora cuando todos los nodos de trabajo que administra (que no sean del modo automático de EKS ni Fargate) y los clientes externos se hayan actualizado para que confíen en la CA sucesora. Para verificarlo, confirme que cada cliente pueda comunicarse correctamente con el servidor de la API mediante la configuración de confianza actualizada. AWS no proporciona un único indicador de que todos los clientes estén preparados, ya que no puede ver el interior de los sistemas externos. Comience el proceso de detección lo antes posible para tener tiempo de identificar todos los clientes.

¿Cómo superviso el progreso de la rotación de la CA en varios clústeres?

Puede hacerlo mediante programación con la AWS CLI o la API de EKS. Use aws eks list-certificate-authorities para cada clúster. Los siguientes campos proporcionan información sobre la situación para la supervisión de flotas:

El siguiente script de ejemplo comprueba el estado de rotación de la CA en una lista de clústeres:

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

Puede ampliarlo para incluir varias regiones y cuentas, y filtrar los clústeres que tengan una CA sucesora agregada, que estén esperando una acción o que se acerquen a la fecha límite de activación automática.

Las notificaciones también se envían por clúster a través de AWS Health y por correo electrónico en cada fase del ciclo de vida de la rotación.

¿Qué ocurre si activo la CA sucesora antes de actualizar todos mis clientes?

Cualquier cliente que no se haya actualizado para confiar en la CA sucesora perderá la conectividad con el clúster de EKS. Después de activar la CA sucesora, el servidor de la API presenta certificados firmados por la CA sucesora. Los clientes que no confíen en ella no superarán la verificación de TLS y no podrán conectarse. Si esto ocurre, puede volver a la CA anterior (si el plazo de reversión sigue disponible) para restablecer la conectividad y, al mismo tiempo, reparar los clientes restantes.

¿Qué ocurre si no cumplo con la fecha límite de caducidad de la CA?

AWS evita que esto suceda. Las barreras de protección automáticas garantizan que el clúster de EKS no llegue a la fecha de caducidad de la CA sin contar con una CA válida. Agregaremos una CA sucesora si no lo ha hecho y la activaremos automáticamente aproximadamente 6 meses antes de que caduque. Si llevó a cabo una reversión después de la primera activación automática, AWS efectuará una última actualización 45 días antes de la fecha de caducidad. El clúster continuará disponible.

Sin embargo, si los nodos de trabajo que administra (que no sean del modo automático de EKS ni Fargate) y los clientes externos no se han actualizado para que confíen en la CA sucesora cuando se produzca la activación automática, esos componentes perderán la conectividad con el servidor de la API.

¿Puedo perder el acceso a mi clúster durante la rotación de la CA?

El clúster de EKS (plano de control) permanece disponible durante todo el ciclo de vida de rotación de la CA. Las barreras de protección de AWS garantizan que el clúster no deje de estar disponible.

Sin embargo, los clientes individuales que administre pueden perder el acceso si no se actualizan para confiar en la CA sucesora antes de activarla. Por ejemplo, si su kubeconfig, la canalización de CI/CD o la herramienta de supervisión continúan haciendo referencia solo a la CA saliente, esos clientes no podrán conectarse cuando se active la CA sucesora. Si esto ocurre, la reversión de la CA puede restablecer el acceso mientras se actualizan los clientes afectados.

¿Tengo que reiniciar mis pods?

La rotación de la CA no afecta directamente a los pods de cargas de trabajo en ejecución. El kubelet de cada nodo gestiona la comunicación con el servidor de la API, por lo que los pods de cargas de trabajo continuarán en ejecución sin interrupciones mientras los nodos estén actualizados. Sin embargo, es posible que los controladores y operadores integrados del clúster que utilizan client-go para comunicarse con el servidor de la API deban reiniciarse tras la activación de la CA sucesora, ya que client-go no vuelve a leer de forma dinámica el paquete de confianza de la CA. En el caso específico de los nodos de AWS Fargate, AWS gestiona la actualización automáticamente mediante el proceso de reciclaje natural de pods.

¿Cambiará mi paquete de confianza durante la rotación?

Sí. Durante la rotación de la CA, el paquete de confianza del clúster contendrá dos autoridades de certificación simultáneamente: la CA saliente y la CA sucesora. Este es el comportamiento esperado durante el periodo de doble confianza y es la forma en que el proceso de rotación mantiene la conectividad de todos los componentes.

Las aplicaciones y los clientes deben configurarse para que confíen en un paquete de CA en lugar de anclarse a un solo certificado CA. No se recomienda el anclaje de CA (validación estricta con una sola CA), ya que provocará errores cuando se actualice el paquete de confianza. Esto se aplica a cualquier configuración de TLS del cliente que se conecte al servidor de la API del clúster de EKS.

¿Por qué mi calendario de notificaciones es diferente del que se describe en esta documentación?

Si el clúster se creó en 2018 o 2019, recibirá notificaciones automáticas según un calendario ajustado. La primera notificación incluirá las fechas pertinentes y los próximos pasos específicos del clúster. Los hitos de notificación estándar se calculan en función de la fecha de caducidad de la CA del clúster. En el caso de los clústeres de este intervalo, las fechas calculadas preceden a la disponibilidad de esta característica, por lo que se aplica un calendario ajustado.