☰

Cómo deshabilitar la aprobación insegura de kubectl hacia el servidor api de kube

tag-icon • tag-icon kubernetes kubeadm
Cómo deshabilitar la aprobación insegura de kubectl hacia el servidor api de kube

Estoy tratando de hacer que mi API de servidor maestro sea más segura para evitar permitir el paso de solicitudes que no sean https.

Muestra de configuración:

$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    server: https://ip:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: REDACTED

Lo cual funciona siempre que utilice las CA correctas.

Mi problema es que también funciona si elimino las CA o tengo CA incorrectas y simplemente aplico la bandera --insecure-skip-tls-verify.

¿Cómo puedo forzar al servidor a permitir conexiones https en lugar de http en la API del servidor?

También he desactivado las solicitudes anónimas.Solicitudes anónimaspero todavía puedo ver que las solicitudes pueden pasar.

Respuesta1

Mi problema es que también funciona si elimino las CA o tengo CA incorrectas y simplemente aplico el indicador --insecure-skip-tls-verify.

Usar --insecure-skip-tls-verifyes altamenteNO RECOMENDADOen el entorno de producción. Se puede utilizar cuando desee realizar algunas pruebas locales o con fines de aprendizaje.

EnKubectldocumentación tienes información:

--insecure-skip-tls-verify

If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure

Por lo tanto, si este indicador se establece como verdadero, siempre omitirá los certificados y no se verificará la identidad del servidor en absoluto. Es similar acurl -k

-k, --insecure
              (TLS) By default, every SSL connection curl makes is verified to
              The  server  connection  is verified by making sure the server's
              interface name, IP address or host name.

Puede proteger su clúster de muchas maneras, pero depende del escenario. Sin embargo, hay algunos principalesPuertos e IP del servidor APIconceptos:

Utilice puerto seguro

De forma predeterminada, el servidor API de Kubernetes funciona HTTPen 2 puertos:

  1. localhost port:
  • está destinado a pruebas y arranque, y para que otros componentes del nodo maestro (programador, controlador-administrador) se comuniquen con la API
  • sin TLS
  • Deshabilite las conexiones http inseguras: el puerto predeterminado es 8080, cámbielo con --insecure-portla bandera. (Se puede desactivar mediante --insecure-port=0)
  • La IP predeterminada es localhost, cámbiela con --insecure-bind-addressla bandera. (Eliminar --insecure-bind-address)
  • La solicitud omite los módulos de autenticación y autorización.
  • solicitud manejada por el(los) módulo(s) de control de admisión.
  • protegido por la necesidad de tener acceso al host
  1. Secure port:
  • utilizar siempre que sea posible Habilitar puerto seguro:
  • utiliza TLS. Establecer certificado con --tls-cert-filey clave con --tls-private-key-filebandera.
  • El valor predeterminado es puerto 6443, cámbielo con -flag -secure-port.
  • La IP predeterminada es la primera non-localhostinterfaz de red, cámbiela con --bind-addressla bandera.
  • Solicitud manejada por módulos de autenticación y autorización.
  • solicitud manejada por el(los) módulo(s) de control de admisión.
  • Se ejecutan los módulos de autenticación y autorización.

Restringir el acceso a la API, lo que significa que debe permitir el acceso a su API solo desde una IP específica o un rango de IP específico (redes autorizadas). No debería ser accesible desde el exterior del mundo. Para hacerlo, puede utilizar reglas de firewall oPolítica de red.

ApagarSolicitudes anónimas, lo cual ya hiciste.

Puede investigarlo --insecure-port=0, sin embargo, debería quedar obsoleto en las versiones más recientes.

Como información adicional, te aconsejo que consultesKubernetes por las malas, especialmente 3 capítulos: Provisioning Compute Resources, Provisioning the CA and Generating TLS Certificates, Generating Kubernetes Configuration Files for Authentication. Puede encontrar allí algunas de las mejores prácticas.

Muy buena explicación de las Kube API-serverbanderas que puedes encontrar enEste artículo

Enlaces útiles sobre seguridad de clústeres:

Los conceptos básicos para mantener seguros los clústeres de Kubernetes: cómo proteger el servidor kube-apiser

Controlar el acceso a la API de Kubernetes

Mejores prácticas de seguridad de Kubernetes

Seguridad de Kubernetes 101: riesgos y 29 mejores prácticas

Controlar el acceso a la API de Kubernetes

Accediendo a los clústeres

información relacionada