Mejora de la seguridad del token de la cuenta de Service
En clústeres anteriores a v1.21, se obtiene un token montando el secreto de la cuenta de servicio en un pod. Los tokens obtenidos de esta manera son permanentes. Este enfoque ya no se recomienda a partir de la versión 1.21. Las cuentas de Service detendrán la creación automática de secretos en clústeres a partir de la versión 1.25.
En clústeres de la versión 1.21 o posterior, puede usar la API TokenRequest para obtener el token y usar el volumen proyectado para montar el token en el pod. Dichos tokens son válidos por un período fijo (una hora por defecto). Antes de la expiración, Kubelet actualiza el token para asegurarse de que el pod siempre utiliza un token válido. Cuando se elimina la cápsula de montaje, el token se invalida automáticamente. Este enfoque se implementa mediante la función BoundServiceAccountTokenVolume para mejorar la seguridad del token de la cuenta de servicio. Los clústeres de v1.21 o posterior habilitan este enfoque de forma predeterminada.
Para una transición sin problemas, la comunidad extiende el período de validez del token a un año por defecto. Después de un año, el token no es válido y los clientes que no admiten la recarga de certificados no pueden acceder al servidor API. Se recomienda que los clientes de versiones anteriores se actualicen lo antes posible. De lo contrario, pueden producirse fallas en el servicio.
Si utiliza un cliente de Kubernetes de una versión pendiente de actualización, la recarga del certificado puede fallar. Las versiones de las bibliotecas cliente de Kubernetes oficialmente admitidas que pueden recargar tokens son las siguientes:
- Go: >= v0.15.7
- Python: >= v12.0.0
- Java: >= v9.0.0
- Javascript: >= v0.10.3
- Ruby: master branch
- Haskell: v0.3.0.0
- C#: >= 7.0.5
Para obtener más información, visite https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens.
Si necesita un token que nunca caduca, también puede gestionar manualmente los secretos de las cuentas de servicio. Aunque se puede crear manualmente un token de cuenta de servicio permanente, se recomienda utilizar un token de corta duración llamando a la API TokenRequest para mayor seguridad.
Diagnóstico
Realice los siguientes pasos para comprobar los clústeres de CCE de v1.21 o posterior:
- Compruebe las versiones adicionales.
- Si está utilizando el complemento prometheus v2.23.34 o anterior, actualícelo a v2.23.34 o posterior.
- Si está utilizando el complemento npd v1.15.0 o anterior, actualícelo a la versión más reciente.
- Utilice kubectl para conectarse al clúster y ejecute el comando kubectl get --raw "/metrics" | grep stale obsoleto para consultar las métricas. Compruebe la métrica denominada serviceaccount_stale_tokens_total.
Si el valor es mayor que 0, algunas cargas de trabajo del clúster pueden estar utilizando una versión anterior de client-go. En este caso, compruebe si este problema se produce en las aplicaciones desplegadas. En caso afirmativo, actualice client-go a la versión especificada por la comunidad lo antes posible. La versión debe ser al menos dos versiones principales del clúster de CCE. Por ejemplo, si la versión de clúster es 1.23, la versión de la biblioteca de dependencias de Kubernetes debe ser al menos 1.19.
