Rota las autoridades certificadoras del clúster de usuario

Google Distributed Cloud usa certificados y claves privadas para autenticar y encriptar las conexiones entre los componentes del sistema en clústeres de usuario. El clúster de administrador crea un nuevo conjunto de autoridades certificadoras (AC) para cada clúster de usuario y usa certificados de la AC a fin de emitir certificados de hoja adicionales para los componentes del sistema. El clúster de administrador gestiona la distribución de los certificados de la AC públicos y los pares de claves de certificados de hoja a los componentes del sistema para establecer su comunicación segura.

La función de rotación de CA del clúster de usuario te permite activar una rotación de los certificados del sistema principal en un clúster de usuario. Durante una rotación, el clúster de administrador reemplaza las CA del sistema principal para el clúster de usuario por las CA recién generadas y distribuye los nuevos certificados de CA públicos y los pares de claves de certificado de hoja a los componentes del sistema del clúster de usuario. La rotación ocurre de manera incremental, de modo que los componentes del sistema puedan seguir comunicarse durante la rotación. Sin embargo, ten en cuenta que las cargas de trabajo y los nodos se reinician durante la rotación.

Existen tres CA del sistema que administra el clúster de administrador para cada clúster de usuario:

  • La CA de etcd protege la comunicación del servidor de la API a las réplicas de etcd y también el tráfico entre réplicas de etcd. Esta CA está autofirmada.
  • La CA del clúster protege la comunicación entre el servidor de la API y todos los clientes internos de la API de Kubernetes (kubelets, controladores, programadores). Esta CA está autofirmada.
  • La CA de proxy principal protege la comunicación con las API agregadas. Esta CA está autofirmada.

Además, es posible que uses una CA de la organización para firmar el certificado configurado por la opción authentication.sni. Esta CA y el certificado SNI se usan para entregar la API de Kubernetes a los clientes fuera del clúster. Administra esta CA y genera el certificado SNI de forma manual. Ni esta CA ni el certificado SNI se ven afectados por la función de rotación de CA del clúster de usuario.

Limitaciones

  • La rotación del certificado de la AC se limita a las AC de etcd, de clúster y de proxy frontal que se mencionaron antes.

  • La rotación del certificado de la AC se limita a los certificados que emite Google Distributed Cloud. No actualiza los certificados emitidos de forma manual por un administrador, incluso si esos certificados están firmados por las AC del sistema.

  • Una rotación de la AC reinicia el servidor de la API, otros procesos del plano de control y cada nodo del clúster varias veces. Cada etapa de una rotación de CA avanza de manera similar a una actualización de clúster. Si bien el clúster de usuario permanece operativo durante una rotación de la AC, debes esperar que las cargas de trabajo se reinicien y reprogramen. También debes esperar períodos breves de tiempo de inactividad del plano de control si tu clúster de usuario no tiene un plano de control de alta disponibilidad.

  • Debes actualizar el archivo kubeconfig del clúster de usuario y los archivos de configuración de autenticación después de una rotación de la AC. Esto se debe a que se revoca el certificado anterior del clúster y las credenciales del archivo kubeconfig ya no funcionan.

  • Después de que se inicia una rotación de AC, no se puede pausar ni revertir.

  • Una rotación de CA puede tardar bastante tiempo en completarse, según el tamaño del clúster de usuario.

Realiza una rotación de AC

  1. Inicia la rotación:

    gkectl update credentials certificate-authorities rotate \
        --config USER_CLUSTER_CONFIG \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    Reemplaza lo siguiente:

    • USER_CLUSTER_CONFIGE: Es la ruta de acceso del archivo de configuración del clúster de usuario.

    • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

    Si la rotación de CA comienza correctamente, verás un mensaje similar a este:

    successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
    

    Si una rotación de AC ya está en curso, verás un mensaje de error similar al siguiente:

    Exit with error:
    admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads
    
  2. Consulta el estado de la rotación:

    gkectl update credentials certificate-authorities status \
        --config USER_CLUSTER_CONFIG \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    El comando anterior informa el CAVersion, que es un número entero que el sistema aumenta de forma automática para diferenciar las AC que se usan antes y después de una rotación. El comando también informa un estado (True o False) que indica si se completó la rotación de la AC y un mensaje que describe qué CAVersion está en uso actualmente por cada componente del sistema.

    Si ya se completó la rotación de la AC, verás un mensaje similar al siguiente:

    State of CARotation with CAVersion 2 is -
    status: True,
    reason: CARotationCompleted,
    message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.
    

    Si la rotación de AC aún está en curso, verás un mensaje similar al siguiente:

    State of CARotation with CAVersion 2 is -
    status: False,
    reason: CARotationProgressed,
    message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.
    

Actualiza las credenciales del clúster de usuario

Cuando se complete la rotación de la AC, debes obtener un archivo kubeconfig nuevo del clúster de usuario del clúster de administrador. Esto se debe a que la rotación de CA revoca la CA en la que se basaba el archivo kubeconfig anterior.

Obtén un archivo kubeconfig nuevo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
    -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
    | base64 --decode > USER_CLUSTER_NAME-kubeconfig

Distribuye el archivo kubeconfig nuevo a todos los que usen este archivo para interactuar con el clúster.

Actualiza los archivos de configuración de autenticación

Una vez completada la rotación de la AC, se deben actualizar y redistribuir los archivos de configuración de autenticación. Sigue las instrucciones vinculadas para actualizar y redistribuir estos archivos después de la rotación de CA:

Rotación de certificados del plano de control

Sin rotación, las AC y los certificados del plano de control del clúster de usuario vencen cinco años después de la fecha en que se creó el clúster. Los certificados del plano de control del clúster de usuario se rotan de forma automática en un plazo de diez horas después de cada actualización del clúster de usuario, pero las AC no lo hacen de forma automática. Esto significa que se debe realizar una rotación de la AC al menos una vez cada cinco años, además de las actualizaciones normales de la versión.

Para evitar que un clúster de usuario deje de estar disponible, los certificados del plano de control se rotan en un plazo de diez horas después de la actualización del clúster de usuario. Cuando esto sucede, aparece un mensaje en el estado de rotación de la AC del clúster de usuario.

Para ver la última versión a la que se actualizó un clúster de usuario cuando se rotaron los certificados del plano de control, haz lo siguiente:

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

La información aparece al final del campo message dentro de las diez horas posteriores a una actualización. Por ejemplo:

Last Leaf Certificates Rotation Version: 1.16.0-gke.0.

Soluciona problemas de rotación de CA

El comando gkectl diagnose admite la verificación del estado esperado de una rotación de CA completa en un clúster de usuario. Para obtener instrucciones sobre cómo ejecutar gkectl diagnose en un clúster de usuario, consulta Diagnostica problemas de clústeres. Si tienes problemas con una rotación de AC, comunícate con Atención al cliente de Google y proporciona el resultado de gkectl diagnose.