El campo streamingConnectionIdleTimeout de una configuración de Kubelet especifica el máximo de tiempo que una conexión de transmisión puede estar inactiva antes de que la conexión se cierre automáticamente. Establecer límites de tiempo de inactividad protege contra ataques de denegación de servicio y contra el riesgo de quedarse sin conexiones. Al ajustar el valor del campo en 0 se desactiva el límite de tiempo de inactividad.

Ejemplo 1: La siguiente configuración de Kubelet deshabilita el límite de tiempo de la conexión de transmisión estableciendo el campo streamingConnectionIdleTimeout en 0.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
streamingConnectionIdleTimeout: 0

Un servidor API de Kubernetes puede autorizar una solicitud mediante uno de varios modos de autorización. El servidor API no realiza ninguna comprobación de autorización en el modo AlwaysAllow porque permite todas las solicitudes.

Ejemplo 1: La siguiente configuración inicia un servidor API de Kubernetes con AlwaysAllow como uno de los modos de autorización.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=...,AlwaysAllow,...
    ...

El administrador de controlador de Kubernetes se inicia sin la marca --root-ca-file, que especifica un archivo de entidad de certificación raíz (CA). Como resultado, el administrador de controlador de Kubernetes no publica la entidad de certificación raíz correspondiente para los pods. Sin la entidad de certificación raíz, los pods no pueden verificar el certificado de servicio del servidor API antes de establecer conexiones. Estas conexiones son vulnerables a un ataque "man-in-the-middle".

Ejemplo 1: La siguiente configuración inicia un administrador de controlador de Kubernetes sin la marca --root-ca-file.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
      ...

Un controlador de Kubernetes inicia la recolección de elementos no utilizados para reclamar los recursos ocupados por los pods finalizados cuando su número excede un umbral. Aunque el exceso de recolección de elementos no utilizados degrada el rendimiento, el umbral predeterminado de 12 500 es demasiado alto para un clúster típico. Antes de que se produzca la recolección de elementos no utilizados, el clúster puede quedarse sin recursos y volverse inestable.

Ejemplo 1: La siguiente configuración inicia un administrador de controlador de Kubernetes sin especificar un umbral.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-controller-manager
    image: example.domain/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
...

Un Kubelet autoriza una solicitud utilizando los modos AlwaysAllow o Webhook. Un modo de autorización no especificado tiene como valor predeterminado AlwaysAllow. El Kubelet no realiza ninguna comprobación de autorización en el modo AlwaysAllow porque permite todas las solicitudes. Debido a que los Kubelets son los agentes principales de Kubernetes para administrar la carga de trabajo del equipo del componente, los atacantes pueden usar solicitudes no controladas para obtener acceso a las API de servicios sensibles a la seguridad y con protección insuficiente.

Ejemplo 1: Kubelet no realiza ninguna comprobación de autorización porque el modo de autorización está configurado en AlwaysAllow.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: AlwaysAllow

Los Kubelets pueden autenticar clientes, pero el paquete de la autoridad de certificación (CA) empleado para verificar el certificado del cliente no está definido en la configuración de Kubelet. Debido a que los Kubelets son los agentes principales de Kubernetes empleados para administrar la carga de trabajo de equipo del componente, los atacantes pueden usar solicitudes anónimas para obtener acceso a las API de servicios sensibles a la seguridad y con protección insuficiente.

Ejemplo 1: La siguiente configuración de Kubelet no contiene el campo clientCAFile que especifica el paquete de CA utilizado para verificar los certificados de cliente.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

De forma predeterminada, un servidor API de Kubernetes no se autentica en Kubelets cuando envía solicitudes. Los Kubelets, que brindan acceso a una amplia variedad de recursos, no pueden verificar la autenticidad de estas solicitudes.

Ejemplo 1: El siguiente comando inicia un servidor API de Kubernetes sin especificar un certificado de cliente y la clave privada correspondiente con las marcas --kubelet-client-certificate y --kubelet-client-key respectivamente para habilitar la autenticación basada en certificados en Kubelets.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
    image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

Un servidor API de Kubernetes envía instrucciones a Kubelets para crear cargas de trabajo, consulta el estado de los recursos administrados por Kubelet y proporciona servicios de reenvío de puertos opcionales a Kubelets. De forma predeterminada, el servidor API no verifica el certificado de servicio de Kubelet antes de establecer la conexión. En consecuencia, esta conexión es vulnerable a un ataque del tipo "man-in-the-middle".

Ejemplo 1: El siguiente comando inicia un servidor API de Kubernetes sin especificar un paquete de certificado raíz para verificar el certificado de servicio de Kubelet con la marca --kubelet-certificate-authority.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
  image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

Un servidor API de Kubernetes puede autorizar una solicitud mediante uno de varios modos de autorización. La autorización Node es un modo de autorización con propósito especial que autoriza específicamente las solicitudes de API realizadas por Kubelets. Esto garantiza que Kubelets tenga el conjunto mínimo de permisos necesarios para funcionar correctamente.

Ejemplo 1: La siguiente configuración inicia un servidor API de Kubernetes sin el modo de autorización Node.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=RBAC,Webhook
    ...

Habilite siempre el controlador de admisión NodeRestriction para un servidor de API de Kubernetes. El controlador de admisión NodeRestriction limita cada Kubelet para modificar sus objetos nodo y Pod y para denegar el acceso a objetos confidenciales del sistema. Así se evita que un nodo comprometido obtenga privilegios en otros nodos de un clúster de Kubernetes.

Ejemplo 1: La siguiente definición de Pod inicia un servidor de API de Kubernetes sin habilitar el controlador de admisión NodeRestriction.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=PodSecurityPolicy
    ...

La ausencia de un controlador de admisión PodSecurityPolicy es indicativo de controles de seguridad débiles, a menos que exista una herramienta alternativa de cumplimiento de políticas para Kubernetes, como K-Rail, Kyverno, OPA/Gatekeeper. El controlador de admisión PodSecurityPolicy hace cumplir las políticas de seguridad de Pod que especifican los atributos de Pod relacionados con la seguridad permitidos en un clúster. Por ejemplo, con PodSecurityPolicy puede prohibir contenedores privilegiados y no permitir la escalada de privilegios de forma predeterminada cada vez que se crea un Pod.

Ejemplo 1: La siguiente definición de Pod inicia un servidor de API de Kubernetes sin habilitar el controlador de admisión PodSecurityPolicy.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=NodeRestriction
    ...

Un servidor API de Kubernetes puede autorizar una solicitud mediante uno de varios modos de autorización. El control de acceso basado en roles (RBAC ) controla el acceso a los recursos informáticos o de red en función de los roles de los usuarios individuales dentro de una organización. RBAC es el modo de autorización más seguro.

Ejemplo 1: La siguiente configuración inicia un servidor API de Kubernetes sin el modo de autorización RBAC.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=Node,Webhook
    ...

Es recomendable definir de manera individualizada permisos que se adhieran al principio de privilegios mínimos. Un contexto de seguridad de Kubernetes define los privilegios y la configuración de control de acceso para un contenedor o Pod. Un contenedor carece de contexto de seguridad si no existe tal configuración tanto a nivel del Pod como a nivel del contenedor.

Ejemplo 1: La siguiente configuración define un Pod sin ningún contexto de seguridad porque no existe el campo securityContext.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP

El controlador de admisión SecurityContextDeny evita que los Pods configuren ciertos campos de SecurityContext que permiten la escalada de privilegios en un clúster de Kubernetes. A menos que exista una herramienta de cumplimiento de políticas alternativa para Kubernetes, como políticas de seguridad de Pod adecuadas, el controlador de admisión SecurityContextDeny debe estar habilitado.

Ejemplo 1: La siguiente definición de Pod inicia un servidor de API de Kubernetes sin habilitar el controlador de admisión SecurityContextDeny.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=NodeRestriction
    ...

Un servidor de API de Kubernetes puede autenticar solicitudes de API mediante tokens de cuenta de servicio. Dichos tokens son generados y firmados por el controlador de tokens de Kubernetes. Utilice la marca --service-account-private-key-file para especificar la clave para firmar el token.

Ejemplo 1: La siguiente configuración inicia un administrador de controlador de Kubernetes sin la marca --service-account-private-key-file.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
        - kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
...

Kubernetes distingue entre los conceptos de cuenta de usuario y cuenta de servicio, que sirve para que un proceso se ejecute en un Pod. El controlador de admisión ServiceAccount automatiza la gestión de la cuenta de servicio. Algunas ventajas del controlador de admisión ServiceAccount son que reduce la exfiltración de tokens de acceso con la rotación de credenciales automatizada y elimina la necesidad de conservar los secretos en el almacenamiento. El controlador de admisión ServiceAccount está habilitado por defecto, pero se ha deshabilitado deliberadamente.

Ejemplo 1: La siguiente definición de Pod inicia un servidor de API de Kubernetes y deshabilita el controlador de admisión ServiceAccount.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=ServiceAccount,PodNodeSelector
    ...

La eliminación del espacio de nombres de Kubernetes elimina todos los objetos en ese espacio de nombres, incluidos los pods y los servicios. El controlador de admisión NamespaceLifecycle mantiene la integridad de los sistemas Kubernetes de dos formas. En primer lugar, evita que se creen objetos en espacios de nombres inexistentes o en espacios de nombres en proceso de finalización. En segundo lugar, evita que se eliminen los espacios de nombres reservados del sistema, los cuales contienen servicios críticos de Kubernetes.

El controlador de admisión NamespaceLifecycle está habilitado de forma predeterminada, pero el comando para iniciar el servidor API de Kubernetes lo ha deshabilitado con la marca --disable-admission-plugin.

Ejemplo 1: La siguiente configuración inicia un servidor API de Kubernetes. La presencia de NamespaceLifecycle incluido en la marca --disable-admission-plugins deshabilita el controlador de admisión NamespaceLifecycle.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=...,NamespaceLifecycle,...
    ...

Kubernetes mantiene datos confidenciales en un clúster etcd. Por lo tanto, cada instancia de etcd solo debe aceptar conexiones de pares autenticados y autorizados, y rechazar cualquier par que use certificados autofirmados para conexiones TLS.

Ejemplo 1: La siguiente configuración inicia una instancia etcd y establece la marca --peer-auto-tls en true. Como resultado, la instancia etcd usa certificados autofirmados para conexiones TLS con pares.

	...
	spec:
	containers:
	- command:
	...
	- etcd
	...
	- --peer-auto-tls=true
	...

Una capacidad de Kubernetes permite que un pod realice acciones root sin dar pleno acceso root. La capacidad CAP_SYS_ADMIN otorga el permiso para realizar la gama más amplia posible de operaciones de administración del sistema en un pod.

Ejemplo 1: El siguiente manifiesto de Kubernetes agrega la capacidad CAP_SYS_ADMIN a un contenedor en un pod.

...
kind: Pod
...
spec:
  containers:
...
    securityContext:
      capabilities:
        add:
        - CAP_SYS_ADMIN
        - SYS_TIME
        ...

De forma predeterminada, a un contenedor de Kubernetes se le niega el acceso a todos los dispositivos del host. El campo privileged permite al contenedor casi todos los mismos privilegios que otros procesos que se ejecutan en el host. Esto expande la superficie de ataque e infringe el principio de ejecutar imágenes con privilegios mínimos.

Ejemplo 1: El pod se ejecuta en modo privilegiado estableciendo privileged: true.

...
kind: Pod
...
spec:
  containers:
    - name: ...
      image: ...
      securityContext:
         privileged: true
...