El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

Kubernetes mantiene datos confidenciales en un clúster etcd. Una instancia de etcd acepta conexiones de clientes sin certificados firmados por entidades de certificación de confianza porque el comando para iniciar el etcd con la marca --client-cert-auth está establecida enfalse.

Ejemplo 1: La siguiente configuración inicia una instancia etcd y establece la marca --client-cert-auth en false.

...
spec:
  containers:
    - command:
  ...
      - etcd
  ...
      --client-cert-auth=false
  ...

Kubernetes mantiene datos confidenciales en un clúster etcd. Cada instancia etcd debe dar servicio a los clientes a través de conexiones TLS, pero faltan las marcas de la línea de comandos para configurar las conexiones TLS.

Ejemplo 1: La siguiente configuración inicia una instancia etcd sin especificar las marcas --cert-file y --key-file para configurar conexiones TLS.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
  ...

Kubernetes mantiene datos confidenciales en un clúster etcd. Cada instancia etcd en un clúster debe siempre comunicarse con sus pares a través de una conexión TLS, pero faltan las marcas de la línea de comandos para configurar la conexión TLS.

Ejemplo 1: La siguiente configuración inicia una instancia etcd sin especificar las marcas de --peer-cert-file y --peer-key-file para configurar una conexión TLS.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
...

Las conexiones desde un servidor API de Kubernetes a Kubelets a menudo contienen datos confidenciales, como secretos y comandos. De forma predeterminada, las conexiones entre el servidor API y los Kubelets están protegidas en tránsito a través de Seguridad de la capa de transporte (TLS). Si la marca --kubelet-https está establecida en false, la comunicación segura está deshabilitada.

Ejemplo 1: La siguiente configuración deshabilita la comunicación segura entre el servidor API y los Kubelets porque el servidor API comienza con la marca --kubelet-https establecida en false.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --kublet-https=false
    - --authorization-mode=RBAC
    image: example.domain/kube-apiserver-amd64:v1.6.0
    ...

Los canales de comunicación de datos insuficientemente protegidos pueden poner los datos críticos de la organización en riesgo de robo, manipulación o divulgación.

Los archivos de registro deben conservarse el tiempo suficiente para facilitar el análisis posterior al incidente y la detección de amenazas, así como para cumplir con los requisitos de cumplimiento. La marca --audit-log-maxage define el número máximo de días de retención de archivos de registro de auditoría antiguos. La marca no está presente en el comando para iniciar un servidor API de Kubernetes o el período de retención está establecido en menos de 30 días.

Ejemplo 1: El siguiente comando inicia un servidor API de Kubernetes y establece la marca --audit-log-maxage en 2 (2 días), un período demasiado breve.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxage=2
    ...

El servidor API de Kubernetes rota automáticamente los archivos de registro. Para facilitar el análisis posterior al incidente y la detección de amenazas, así como para cumplir con los requisitos de cumplimiento, debe conservar una cantidad suficiente de datos de registro. La marca --audit-log-maxbackup define el número máximo de archivos de registro que se deben retener. O esta marca no está presente en el comando para iniciar un servidor API de Kubernetes o la cantidad máxima de archivos de registro para retener es inferior a 10.

Ejemplo 1: El siguiente comando inicia un servidor API de Kubernetes y establece la marca --audit-log-maxbackup en 2, que conserva solo dos archivos de registro, lo que es insuficiente.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxbackup=2
    ...

El servidor API de Kubernetes rota automáticamente los archivos de registro. Para facilitar el análisis posterior al incidente y la detección de amenazas, así como para cumplir con los requisitos de cumplimiento, debe conservar una cantidad suficiente de datos de registro. La marca --audit-log-maxsize establece el tamaño máximo en megabytes (MB) del archivo de registro de auditoría antes de rotarlo automáticamente. O esta marca no está presente en el comando para iniciar un servidor API de Kubernetes o el tamaño máximo del archivo de registro de auditoría está establecido en menos de 100 MB.

Ejemplo 1: El siguiente comando inicia un servidor API de Kubernetes y establece la marca --audit-log-maxsize en 2 (megabytes), lo que es insuficiente.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - ----audit-log-maxsize=2
    ...

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

Si el ajuste ProtectKernelDefaults se deja sin establecer o se establece en false, un Kubelet puede modificar los parámetros del kernel en tiempo de ejecución. Los parámetros del kernel deben optimizarse y reforzarse antes de la implementación de Kubernetes. Otorgar a un Kubelet la capacidad de alterar los parámetros del kernel amplía la superficie de ataque del sistema operativo host.

Ejemplo 1: La siguiente configuración de Kubelet permite que un Kubelet configure los parámetros del kernel debido al ajuste ProtectKernelDefaults: false.

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

Existe una configuración que permite a Kubelets atender solicitudes anónimas. Las solicitudes anónimas no son rechazadas por ningún método de autenticación configurado. Debido a que los Kubelets son los agentes principales de Kubernetes 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: El siguiente archivo de configuración permite que un Kubelet atienda solicitudes anónimas porque el campo anonymous está configurado en enabled:true.

...
kind: KubeletConfiguration
...
authentication:
  anonymous:
    enabled: true
...

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
...