Tecnología · GUÍA PRÁCTICA
¿kubectl muestra x509: certificate signed by unknown authority? Demuestra la ruta de confianza efectiva
Identifica el kubeconfig activo, el endpoint, la CA, el proxy y la cadena presentada antes de sustituir credenciales o desactivar TLS.
Un error x509 de kubectl no indica qué configuración, endpoint o cadena falló. Empieza por demostrar los valores efectivos que utilizó el proceso actual.
Esta guía separa un kubeconfig obsoleto o combinado, un proxy inesperado, un certificado sustituido del servidor API y un nombre de host incorrecto antes de cambiar la confianza.
Fija el cliente, el error y el contexto de ejecución
Guarda el error completo, comando, hora, versión y entorno. Registra HOME, KUBECONFIG y opciones explícitas sin copiar credenciales en incidencias ni chats.
No borres ~/.kube, sustituyas todas las CA ni añadas una opción insegura al principio. El error aún no identifica archivo, endpoint, proxy o cadena.
Demuestra el kubeconfig efectivo y el contexto actual
Ejecuta current-context e inspecciona config view --minify. KUBECONFIG combina archivos y conserva la primera clave, mientras --kubeconfig elige uno.
Usa --raw solo en una sesión local protegida y compara la salida efectiva con los archivos esperados para descartar un archivo obsoleto, otro HOME o una cuenta distinta.
Extrae el endpoint y el ancla sin modificarlos
Registra server URL, tls-server-name, proxy-url, ruta CA y presencia de CA data. Los datos incrustados prevalecen sobre el archivo CA.
Decodifica la CA solo en un temporal restringido y registra sujeto, emisor, validez y huella; para un archivo CA, resuelve su ruta y calcula el hash.
Inspecciona el certificado presentado por la misma ruta
Examina desde la misma red, VPN, contenedor o runner y usa OpenSSL -connect, -servername y -verify_return_error.
Comprueba proxy-url, HTTPS_PROXY, HTTP_PROXY y NO_PROXY; compara SAN, cadena emisora y huellas con el endpoint previsto.
Clasifica la discrepancia antes de repararla
Separa configuración antigua, contexto combinado incorrecto, datos CA que sobrescriben, intermedio ausente, certificado del proxy y desajuste SNI.
No confíes ciegamente en el certificado final de un endpoint inesperado; el ancla debe venir del propietario o de un canal autenticado.
Repara un único contrato de confianza
En un clúster administrado, actualiza credenciales con el comando oficial y compara entradas; en uno propio, instala la CA verificada en la entrada prevista.
Corrige el proxy si no corresponde; si es obligatorio, obtiene su CA por el proceso autenticado de la organización y no desactives la verificación.
Verifica en el contexto original y conserva la reversión
Repite con el mismo kubeconfig, contexto, red y comando, y confirma que endpoint y emisor corresponden al clúster previsto.
Registra hashes, huella CA, endpoint, decisión del proxy, comando de actualización y archivo de reversión; elimina temporales con seguridad.
