Versión imprimible multipagina. Haga click aquí para imprimir.

Volver a la vista normal de esta página.

Seguridad

1 - Vista General de Seguridad Cloud Native

Esta descripción general define un modelo para la seguridad de Kubernetes en el contexto de Seguridad en Cloud Native.

Las 4C de Seguridad en Cloud Native

Puede pensar en seguridad por capas. Las 4C de la seguridad en Cloud Native son la nube (Cloud), Clústeres, Contenedores y Código.

Las 4C de Seguridad en Cloud Native

Cada capa del modelo de seguridad Cloud Native es basada en la siguiente capa más externa. La capa de código se beneficia de una base sólida (nube, clúster, contenedor) de capas seguras. No podemos garantizar la seguridad aplicando solo seguridad a nivel del código, y usar estándares de seguridad deficientes en las otras capas.

Nube (Cloud)

En muchos sentidos, la nube (o los servidores o el centro de datos corporativo) es la base de computador confiable de un clúster de Kubernetes. Si la capa de la nube es vulnerable (o configurado de alguna manera vulnerable), por consecuencia no hay garantía de que los componentes construidos encima de la base sean seguros. Cada proveedor de la nube tiene recomendaciones de seguridad para ejecutar las cargas de trabajo de forma segura en sus entornos.

Seguridad del proveedor de la nube

Si está ejecutando un clúster de Kubernetes en su propio hardware o en un proveedor de nube diferente, consulte la documentación para conocer las mejores prácticas de seguridad. A continuación, algunos enlaces a la documentación de seguridad de los proveedores de nube más populares:

Cloud provider security
Proveedor IaaS Link
Alibaba Cloud https://www.alibabacloud.com/trust-center
Amazon Web Services https://aws.amazon.com/security/
Google Cloud Platform https://cloud.google.com/security/
Huawei Cloud https://www.huaweicloud.com/intl/es-us/securecenter/overallsafety
IBM Cloud https://www.ibm.com/cloud/security
Microsoft Azure https://docs.microsoft.com/en-us/azure/security/azure-security
Oracle Cloud Infrastructure https://www.oracle.com/security/
VMWare VSphere https://www.vmware.com/security/hardening-guides.html

Seguridad de la Infraestructura

Sugerencias para proteger su infraestructura en un clúster de Kubernetes:

Infrastructure security
Área de Interés para la Infraestructura de Kubernetes Recomendación
Acceso de red al Plano de Control Todo acceso público al plano de control del Kubernetes en Internet no está permitido y es controlado por listas de control de acceso a la red estrictas a un conjunto de direcciones IP necesarias para administrar el clúster.
Acceso a la red de los Nodos Los nodos deben ser configurados para solo aceptar conexiones (por medio de listas de control de acceso a la red) desde el plano de control en los puertos especificados y aceptar conexiones para servicios en Kubernetes del tipo NodePort y LoadBalancer. Si es posible, estos nodos no deben exponerse públicamente en Internet.
Acceso a la API de Kubernetes del proveedor de la nube Cada proveedor de la nube debe dar un conjunto de permisos al plano de control y nodos del Kubernetes. Es mejor otorgar al clúster el permiso de acceso al proveedor de nube siguiendo el principio de mínimo privilegio para los recursos que necesite administrar. La documentación del Kops ofrece información sobre las políticas y roles de IAM.
Acceso a etcd El acceso a etcd (banco de datos de Kubernetes) debe ser limitado apenas al plano de control. Dependiendo de su configuración, debería intentar usar etcd sobre TLS. Puede encontrar mas información en la documentación de etcd.
Encriptación etcd Siempre que sea posible, es una buena práctica encriptar todas las unidades de almacenamiento. Etcd mantiene el estado de todo el clúster (incluidos los Secretos), por lo que su disco debe estar encriptado.

Clúster

Existen dos áreas de preocupación para proteger Kubernetes:

  • Protección de las configuraciones de los componentes del clúster.
  • Protección de las aplicaciones que se ejecutan en el clúster.

Componentes del Clúster

Si desea proteger su clúster de accesos accidentales o maliciosos y adoptar buenas prácticas de seguridad, a continuación sigue estos consejos sobre como proteger el clúster.

Componentes del clúster (su aplicación)

Dependiendo de la superficie de ataque de su aplicación, es posible que desee concentrarse en temas de seguridad específicos. Por ejemplo: si está ejecutando un servicio (Servicio A) que es crítico en una cadena de otros recursos y otra carga de trabajo separada (Servicio B) que es vulnerable a un ataque de sobrecarga de recursos, el riesgo de comprometer el Servicio A es alto si no limita las funciones del Servicio B. La siguiente tabla enumera áreas de atención de seguridad y recomendaciones para proteger las cargas de trabajo que se ejecutan en Kubernetes:

Áreas para la seguridad de la carga del trabajo Recomendación
Autorización RBAC (acceso a la API Kubernetes) https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Autenticación https://kubernetes.io/docs/concepts/security/controlling-access/
Administrar secretos en la aplicación (encriptar el etcd - dato en reposo) https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Políticas de seguridad de Pod https://kubernetes.io/docs/concepts/policy/pod-security-policy/
Calidad de servicio (y gestión de recursos del clúster) https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
Políticas de Red https://kubernetes.io/docs/concepts/services-networking/network-policies/
TLS para Kubernetes Ingress https://kubernetes.io/docs/concepts/services-networking/ingress/#tls

Contenedor

La seguridad de los contenedores está fuera del alcance de la guía. Aquí hay recomendaciones generales y enlaces para explorar este tema:

Área de Interés para Contenedores Recomendación
Escáneres de vulnerabilidad de contenedores y seguridad de dependencia del sistema operativo Como parte del paso de la creación de la imagen, se debe utilizar un escáner de contenedores para detectar vulnerabilidades.
Firma de Imágenes y Aplicación Firma de imágenes de contenedores para mantener un sistema confiable para el contenido de sus contenedores.
Prohibir Usuarios Privilegiados Al crear contenedores, consulte la documentación para crear usuarios dentro de los contenedores con el menor privilegio necesario para cumplir con el propósito del contenedor en el sistema operativo.
Utilice el contenedor de tiempo de ejecución con el aislamiento más fuerte Seleccione clases del contenedor runtime con el proveedor de aislamiento más fuerte.

Código

El código de la aplicación es una de las principales superficies de ataque sobre las que tenemos más control. Aunque la protección del código de la aplicación está fuera del tema de seguridad de Kubernetes, aquí algunas recomendaciones para proteger el código de su aplicación:

Seguridad del código

Code security
Áreas de Atención para el Código Recomendación
Acceso solo a través de TLS Si su código necesita comunicarse a través de TCP, ejecute un handshake TLS con el cliente anticipadamente. Con la excepción de algunos casos, encripte todo lo que está en tránsito. Yendo un paso más allá, es una buena idea cifrar el tráfico de red entre los servicios. Esto se puede hacer a través del proceso de autenticación mutua o mTLS, que realiza una verificación bilateral de la comunicación a través de los certificados en los servicios.
Limitación de rangos de puertos de comunicación Esta recomendación puede ser un poco evidente, pero siempre que sea posible, solo debe exponer los puertos de su servicio que son absolutamente esenciales para la comunicación o la recopilación de métricas.
Seguridad en dependencia de terceros Es una buena práctica comprobar periódicamente las bibliotecas de terceros de su aplicación en busca de vulnerabilidades de seguridad. Cada lenguaje de programación tiene una herramienta para realizar esta verificación de forma automática.
Análisis de código estático La mayoría de los lenguajes proporcionan una forma de analizar el código en busca de prácticas de codificación potencialmente inseguras. Siempre que sea posible, debe automatizar los escaneos utilizando herramientas que puedan escanear las bases del código en busca de errores de seguridad comunes. Algunas de las herramientas se pueden encontrar en OWASP Source Code Analysis Tools.
Ataques de sondeo dinámico Existen algunas herramientas automatizadas que puede ejecutar en su servicio para explorar algunos de los ataques más conocidos. Esto incluye la inyección de SQL, CSRF y XSS. Una de las herramientas de análisis dinámico más populares es la OWASP Zed Attack proxy.

Siguientes pasos

Obtenga más información sobre los temas de seguridad de Kubernetes:

2 - Políticas de Seguridad del Pod

En vez de usar PodSecurityPolicy, puedes aplicar restricciones similares en Pods usando cualquiera o los dos:

Para obtener una guía de migración, consulte Migrar de PodSecurityPolicy al Controlador de Admisión de Seguridad de Pod Integrado. Para obtener más información sobre la eliminación de esta API, consulte Obsoleto de PodSecurityPolicy: Pasado, Presente y Futuro.

Si no está ejecutando Kubernetes v1.32, consulte la documentación para su versión de Kubernetes.

3 - Controlando el Acceso a la API de Kubernetes

Esta página proporciona información sobre cómo controlar el acceso a la API de Kubernetes.

Los usuarios acceden a la API de Kubernetes usando kubectl, bibliotecas de cliente, o haciendo peticiones REST. Usuarios y Kubernetes service accounts pueden ser autorizados para acceder a la API. Cuando una petición llega a la API, pasa por varias etapas, están ilustradas en el siguiente diagrama:

Diagrama de pasos para una petición a la API de Kubernetes

Seguridad en la capa de transporte

En un cluster típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. El API Server presenta un certificado. Este certificado puede ser firmando usando un certificado de autoridad privada (CA) o basado en una llave pública relacionada generalmente a un CA reconocido.

Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado CA configurado dentro de su ~/.kube/config en el cliente, entonces se podrá confiar en la conexión y estar seguro que no será comprometida.

El cliente puede presentar un certificado TLS de cliente en esta etapa.

Autenticación

Una vez que se estableció la conexión TLS, las peticiones HTTP avanzan a la etapa de autenticación. Esto se muestra en el paso 1 del diagrama. El script de creación del cluster o el administrador del cluster puede configurar el API Server para ejecutar uno o mas módulos de autenticación. Los Autenticadores están descritos con más detalle en Authentication.

La entrada al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente examina las cabeceras y/o el certificado del cliente.

Los modulos de autenticación incluyen certificado de cliente, contraseña, tokens planos, tokens de inicio y JSON Web Tokens (usados para los service accounts).

Múltiples módulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente, hasta que uno de ellos tiene éxito.

Si la petición no puede ser autenticada, la misma es rechazada con un código HTTP 401. Si la autenticación tiene éxito, el usuario es validado con el username específico, y el nombre de usuario esta disponible para los pasos siguientes. Algunos autenticadores también proporcionan membresías de grupo al usuario, mientras que otros no lo hacen.

Aunque Kubernetes utiliza los nombres de usuario para tomar decisiones durante el control de acceso y para registrar las peticiones de entrada, no tiene un objeto User ni tampoco almacena información sobre los usuarios en la API.

Autorización

Después de autenticar la petición como proveniente de un usuario específico, la petición debe ser autorizada. Esto se muestra en el paso 2 del diagrama.

Una petición debe incluir el nombre de usuario solicitante, la acción solicitada y el objeto afectado por la acción. La petición es autorizada si hay una política existente que declare que el usuario tiene permisos para la realizar la acción.

Por ejemplo, si el usuario Bob tiene la siguiente política, entonces puede leer pods solamente en el namespace projectCaribou:

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

Si Bob hace la siguiente petición, será autorizada dado que tiene permitido leer los objetos en el namespace projectCaribou :

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

En cambio, si Bob en su petición intenta escribir (create o update) en los objetos del namespace projectCaribou, la petición será denegada. Del mismo modo, si Bob hace una petición para leer (get) objetos en otro namespace como projectFish, la autorización también será denegada.

Las autorizaciones en Kubernetes requieren que se usen atributos REST comunes para interactuar con el existente sistema de control de toda la organización o del proveedor cloud. Es importante usar formatos REST porque esos sistemas de control pueden interactuar con otras APIs además de la API de Kubernetes.

Kubernetes soporta múltiples módulos de autorización, como el modo ABAC, el modo RBAC y el modo Webhook. Cuando un administrador crea un cluster, se realiza la configuración de los módulos de autorización que deben ser usados con la API del server. Si más de uno módulo de autorización es configurado, Kubernetes verificada cada uno y si alguno de ellos autoriza la petición entonces la misma se ejecuta. Si todos los modules deniegan la petición, entonces la misma es denegada (Con un error HTTP con código 403).

Para leer más acerca de las autorizaciones en Kubernetes, incluyendo detalles sobre cómo crear politicas usando los módulos de autorización soportados, vea Authorization.

Control de Admisión

Los módulos de Control de Admisión son módulos de software que solo pueden modificar o rechazar peticiones. Adicionalmente a los atributos disponibles en los módulos de Autorización, los de Control de Admisión pueden acceder al contenido del objeto que esta siendo creado o modificado.

Los Controles de Admisión actúan en las peticiones que crean, modifican, borran o se conectan (proxy) a un objeto. Cuando múltiples módulos de control de admisión son configurados, son llamados en orden.

Esto se muestra en el paso 3 del diagrama.

A diferencia de los módulos de Autorización y Autenticación, si uno de los módulos de control de admisión rechaza la petición, entonces es inmediatamente rechazada.

Adicionalmente a rechazar objetos, los controles de admisión también permiten establecer valores predeterminados complejos.

Los módulos de Control de Admisión disponibles están descritos en Admission Controllers.

Cuando una petición pasa todos los controles de admisión, esta es validada usando la rutinas de validación para el objeto API correspondiente y luego es escrita en el objeto.

Puertos e IPs del API server

La discusión previa aplica a peticiones enviadas a un puerto seguro del servidor API (el caso típico). El servidor API puede en realidad servir en 2 puertos:

Por defecto, la API de Kubernetes entrega HTTP en 2 puertos:

  1. puerto localhost:

    • debe usarse para testeo e iniciar el sistema y para otros componentes del nodo maestro (scheduler, controller-manager) para hablar con la API
    • no se usa TLS
    • el puerto predeterminado es el 8080
    • la IP por defecto es localhost, la puede cambiar con el flag --insecure-bind-address.
    • la petición no pasa por los mecanismos de autenticación ni autorización
    • peticiones controladas por los modulos de control de admisión.
    • protegidas por necesidad para tener acceso al host

  2. “Puerto seguro”:

    • usar siempre que sea posible
    • usa TLS. Se configura el certificado con el flag --tls-cert-file y la clave con --tls-private-key-file.
    • el puerto predeterminado es 6443, se cambia con el flag --secure-port.
    • la IP por defecto es la primer interface que no es la localhost. se cambia con el flag --bind-address.
    • peticiones controladas por los módulos de autenticación y autorización.
    • peticiones controladas por los módulos de control de admisión.

Siguientes pasos

En los siguientes enlaces, encontrará mucha más documentación sobre autenticación, autorización y el control de acceso a la API: